Many of these ideas build on Pravir Chandra's Software Assurance Maturity Model (Version 1.0) and the Building Security In Maturity Model by Gary McGraw, Brian Chess, and Sammy Migues. Both works are licensed under the Creative Commons Attribution-Share Alike 3.0 License.
This article was also heavily influenced by Microsoft's SDL process.
The next several blog entries will cover my current project: providing a template or starting point for organization's internal application security portal. This post is the second of many to come.
Previous Internal AppSec Portals Posts:
Introduction
This post will cover providing application security resources for developers, including
- Policies
- Guidance
- Requirements
- Vulnerabilities
- and External Resources
GoalsThe purpose behind this set of resources is to provide all the information a developer needs to write secure code. Developers cannot be expected to pull secure code out of the air. Guidelines, coding standards, and security requirements must be spelled out to ensure everyone understands their responsibilities and the organization's expectations.
Additionally, developers MUST be provided with security awareness training AND training against this material.
Policies
Security Policies
Most organizations define a set of security policies that govern acceptable use of information systems, methods for labeling and handling confidential data, and procedures for addressing policy violations. These same concepts should be extended to cover application security, compliance, and privacy policies.
Security policies should express the organization's dedication to the topics below. These topics do not necessarily have to define the process or implementation of each policy area, only statements mandating their use.
- Mandatory, periodic application security training
- Adherence to application security guidance and coding standards
- Use of a formal risk management process
- Risk categorization of data and applications
- Creation and maintenance of application security portfolios
- Use of approved secure development processes
- Dedication to meeting regulatory and compliance standards in each application project
- Inclusion and validation of security, privacy, and compliance requirements throughout the development process
- Establishment of a minimum level of assurance for application security, privacy, and compliance
In addition to security policies, organizations should maintain policies governing how personally identifiable information such as social security numbers, account numbers, or other data is handled. These policies should send a clear message to project teams that protecting users' private data is important. These policies should cover topics such as:
- Identification and categorization of private data
- Collection, storage, and transmission of private data
- Inclusion and validation of privacy requirements during the development process
- Establishment of a minimum level of assurance for privacy data
Microsoft's Privacy Guidelines for Developing Software Products and Services
Microsoft SDL Privacy Questionnaire
Microsoft SDL Privacy Requirements
Microsoft SDL Privacy At A Glance
Compliance Policies
There are a wide variety of compliance and regulatory standards that apply to organizations, data, and functionality. Project teams cannot spend all of their time researching these standards. At the organization level, compliance standards should be identified and a process should be created to assist developers in determining which regulations apply to their project. Compliance policies should include the following topics:
- Identification of compliance and regulatory standards
- Process for determining standards that apply to each software project
- Inclusion and validation of compliance requirements during the development process
- Establishment of a minimum level of assurance for software compliance
Organizations should collect and publish internal guidance to be consumed by project teams. Guidance should not only include secure coding standards, but also approved frameworks, security services, architectures, and environments. These items should be provided in a way that clearly communicates approaches or code that is approved, an organization standard, or unapproved.
Approved Libraries and Frameworks
Software can be developed in a variety of languages and often includes external third party libraries. ASP.NET applications often include libraries such as ASP.NET MVC and Microsoft's AntiXSS library. Java applications may include Struts, Spring, Hibernate, Velocity, and many others. Additionally, developers may want to develop software in PHP, Python, Ruby, Perl, and other languages.
Organizations must communicate which of these languages and frameworks are approved for use in software projects. Guidance should start with a simple list of languages and frameworks the organization has approved or disapproved. As development groups request approval for additional 3rd party libraries and develop successful applications, a list of standards should be created for specific architecture or project types.
For example, an organization may list the following standards for MVC applications in Java and ASP.NET (they typically would expand upon the descriptions as well):
Database Driven Java MVC Application
The organization has standardized on using the following frameworks for Database Driven J2EE MVC applications:
- Language: Java 1.6
- MVC Framework: Struts 2.x
- Dependency Injection Framework: Spring 2.x
- ORM Layer: Hibernate 3.x
The organization has standardized on using the following frameworks for Database Drive ASP.NET MVC applications:
- Language: ASP.NET 3.5
- MVC Framework: ASP.NET MVC 1.x
- Other: Microsoft AntiXSS Library 2.x
Examples of frameworks an organization may produce are:
- Secure methods for accessing security services (discussed in the next section)
- Secure methods for calling security resources (discussed in the next section)
- Input validation frameworks
- Unified authentication flows
- Authorization or entitlement frameworks
- and many more...
Security Services and Resources
A collection of applications often utilize common web services, authentication servers, LDAP servers, or other entities. Organizations should maintain a list of approved security services and resources, guidance informing project teams when it is appropriate to include the services or resources in a project, and the proper method for accessing or calling the service or resource.
Standardization on central services or resources can greatly reduce efforts required to validate applications' security. It also may eliminate the need to create an authentication or authorization strategy for each new project.
Examples of security services organizations may standardize on are:
- Authentication/single sign-on servers
- Web services providing entitlement or authorization details
- Web services that serve as a central point for accessing encrypted credit card data
- Web services that provide centralized auditing and logging capabilities
- Web services that provide centralized key management and cryptography
- LDAP servers containing authentication and authorization information
- Centralized, redundant file storage and backup
Secure Coding Standards
Developers are very good a developing software and implementing business requirements quickly and effectively; however, college, their programming textbook, or their expert programmer friend probably never taught them how to write secure code. In order to ensure developers write secure and consistent code, organizations need to provide secure coding standards to teach and support secure coding practices.
Secure coding standards should be presented in manner that can both teach developers and be used as a quick reference during the development process. It should contain code examples in all approved languages and for each framework. It should also provide examples of what NOT to do. Here is a list of items to consider including within a secure coding standard:
- Description of the standard
- Statement of why its important
- Explanation of when to use the approach or standard
- Vulnerabilities that may result if the standard is not observed
- Code examples in each language and framework
- Code examples of what NOT to do
- Links to external resources that provide additional information
Once these standards are written, they can be matched up with security, compliance, and privacy requirements, which are discussed in the next section. These coding standards allow organizations to hold project teams accountable for writing code that satisfies requirements.
Requirements
A set of common security requirements should be created and shared throughout the organization. These requirements should provide discrete, testable assertions which can be verified throughout the application development process (More on this idea in a later post). An abbreviated example of a security requirement is:
"Applications must use parameterized queries or prepared statements when querying relational databases. Untrusted data must not be concatenated within dynamic SQL query strings."
Another example related to integrating security services guidance is:
"All external facing applications must utilize the organization's standard, centralized authentication server."
The focus of these requirements is to provide a set of rules that developers can be and are held accountable for. Developers often cannot be security experts, but they can be trained to follow and execute on software project requirements. Assuming the organization documents the appropriate guidance and links this guidance to security requirements, development teams can be held accountable for security requirements in the same way they are held to business requirements.
As business requirements are typically implemented based on a prioritized list, it will also be important to allow a member of the organization's security department help prioritize security requirements with project managers.
In addition to security related requirements, privacy and compliance requirements must also be identified. These requirements should be written to satisfy the policies discussed in the "Compliance Policies" and "Privacy Policies" sections above.
Once a reasonable set of security, privacy, and compliance requirements have been established, a set of requirements profiles should be created for various project types. For example, applications that must be PCI compliant will have many compliance requirements that overlap with security and privacy requirements. The requirements profile "High Risk PCI Application" should contain a preprioritized list of requirements that combine and simplify items from the each category.
Vulnerabilities
During the development process, application vulnerabilities are often identified and reported to project teams. Typically, these reports provide a set of recommendations that will eliminate the vulnerability. Depending on the source of these recommendations (a penetration testing tool, code review tool, internal security team, or third party consulting company) the prescriptive advice may or may not coincide with the organization's approved method for eliminating a vulnerability. While general technical flaws like cross-site scripting are fairly straight forward, business logic, authentication, and authorization related issues may require organization specific approaches.
Organizations should maintain a list of vulnerabilities and should link each vulnerability to security, compliance, and privacy requirements that address the issues. This list of vulnerabilities should provide a short explanation of each issue and should label requirements with "Required", "Recommended", and "Optional." The explanation for each issue does not need to be long, many application security sites like OWASP already provide detailed descriptions for many vulnerabilities. Below is an example of how an organization can document vulnerabilities within an internal AppSec Portal:
SQL Injection
SQL injection occurs when untrusted data is interpreted by the database as SQL commands. This issue may allow users to read, modify, or destroy data without authorization.
The following security, privacy, and compliance requirements should be used to address this vulnerability:
Required:
- Security: <link to parameterized queries and prepared statements requirement>
- Compliance: <link to compliance requirement A>
- Security: <link to input validation framework requirement>
- Security & Compliance: <link to auditing and logging requirement>
External Resources
Finally, the organization should provide a set of external resources that project and security teams can use to research application security topics and news.
Posts
No comments:
Post a Comment