Writing not only functional but secure applications is not a new concept or idea that has taken the Industry by storm. However, many Government and Commercial Organizations are still not adhering to or requiring their Organizations to adopt, implement, and build in security into the Systems Development Life Cycle process. Instead, Organizations are continuing to focus on the functional aspects of software, only to be surprised when a weakness or vulnerability in the software leads to a compromise, resulting in thousands of records stolen in the process. So the fundemental question is why is this still a hard problem for Organizations to tackle?
Application Security is still fraught with challenges (Challey, 2009) which gives Application Security the appearance of an enigma due to the following:
- Application Security Changes Rapidly
- With the growing landscape and priority of threats, vulnerabilities, and weaknesses, an Organization can quickly fall behind.
- Changing Landscape
- The technology landscape is constantly changing. This requires constant awareness and education of new technologies to prepare for and address new threat vectors and attack landscapes.
- Becoming an Enabler
- Security is typically viewed as a disabler because of the perception Security mandates and controls hinders and slows processes. Within the Software Development processes Security is viewed as an overhead in terms of additional financial and human resources as well as slowing down the “time to market” for the applications.
Because of the stigma of Application Security as an enigma, the Challenges in the reasons implementing an Application Security program internally within an Organization, and the Gap in academia in teaching Developers how to write both functional and secure applications, Organizations – both Government and Commercial – continue to be front page news items as a result of the compromise of one of their Applications.
(Read more: How to have unique passwords for each website and yet remember them easily?)
Most Government Organizations and Commercial Organizations that work directly with the Government, deal with medical records, or are held to certain legal requirements are typically held to the regulatory requirement from a Security perspective of NIST (National institute of Standards and Technology). NIST provides specific guidelines known as Special Publications that an Organization can leverage to prepare their Organization for a NIST audit, certification, and accredidation. There an Organization must understand the NIST requirements and it is this understanding that allows allow the Organization to be uniquely positioned and prepared for and receive accredidation, especially with building security into your System Development Life Cycle (SDLC) process.
(Kissel et al, 2008) offers a guide in building in the necessary security and controls into the various phases of the SDLC. (Kissel et al, 2008) is a complement to the Risk Management Framework presented in (Ross, 2011). To better understand the RMF and its relation to Application Security, the following 3 Tier (Ross, 2011) understanding of Risk controls within an Organization is adopted to identify where the SDLC fits in:
- Tier 1 – Organizational. A Risk Assessment at this Tier is focused on the Organization’s Information Security programs, policies, procedures, and guidance. Risk Acceptance, Avoidance, Mitigation, Sharing, and Transfer is a key element of the driver behind the IS Program. Investment decisions are then determined based on the Risk posture, to include procurement activities, controls, and monitoring activities. This is equivalent to the Management Controls listed in (Swanson, 2011) and (Guttman and Roback, 2006). From an SDLC perspective, this includes the Life Cycle Assessment process, focusing on a Program, Policies, and Procedures for SDLC Activities that include identification and remediation of Vulnerabilities within the SDLC Phases (Initiation, Deployment/Acquisition, Implementation/Assessment, Operation/Maintenance, and Disposal).
- Tier 2 – Mission / Business Processes. A Risk Assessment can implement Enterprise and Security Architecture design decisions, common Controls, Acquisition partners and Vendors, Risk Awareness for Business Processes, and demonstrating Security as a Business Enabler by interpreting Policies and Procedures as Business essentials that help in the streamlining of Business Operations vs a mandated necessary. From an SDLC perspective, this is building in the Gate Controls providing check-points between the Phases, Training, and Change Management.
- Tier 3 – Information Systems. A Risk Assessment can drive the design and implementation decisions for the Security Controls from a technology perspective. In addition, Operational decisions can be determined, which include monitoring, authorization, and maintenance. From an SDLC perspective, this is the implementation of the technologies in the Technical Controls that will be introduced to help meet the Gate requirements, as well as the Policy requirements for Identification and Authentication (I&A), Access Controls (Logical), and Auditing within the Applications.
It is, therefore, important to align your Organization with the requirements in NIST SP 800-64 with the Risk Management Framework. The approach breaks down each of the phases of the SDLC and within each phase, assign and align each Control Objective with a Control Number, Description, Level, and a recommended set of decision points to include within a Gate process that will provide for a Go / No Go decision to the next phase. Table 1 is a sample of the approach within the Initiation Phase of the SDLC:
Control Number | Control | Description | Metrics | Level | Recommended Control Gates |
Initiation | |||||
I.1.1 | Identify sources of Security Requirements | Security sources are requirements to implement security controls in accordance with laws, regulations, and compliance standards. | Number of Security Requirements | 1 | System Concept Review that verifies the concept is in line with Organization's objectives and budgetary constraints |
I.1.2 | Ensuring all Key Stakeholders have a Common Understanding | All relevant Development, Security, and Business Stakeholders are fully aware of and an understanding of the Security Implications, Considerations, and Requirements per the Identified Sources as well as the Organization's Policies, Procedures, and Guidelines. |
| 1 | |
I.1.3 | Establishment of a Security Guide as part of the SDLC Process | The Guide consists of the following information: Security Responsibilities (Roles and Responsibilities); Security Reporting Metrics; Certification and Accreditation Process (Go / No Go Decision at appropriate Gates between Phases); Security Testing and Assessment Techniques (static code analysis, dynamic scanning, pentesting, fuzzing, etc); Security Document and Requirements Deliverables; Secure Design, Architecture, and Coding Practices (in accordance with Security Requirements). |
| 2 | |
I.2.1 | Security Categorization Process | A process is in place that will categorize the Application in accordance with the type of data being processed, the deployment location of the application, and the types of users of the application. A Business Impact Analysis procedure is an integral part of this process and should be expanded to include the Security Categorization of each Application. In addition to the classification of the Application, other factors to consider are the Confidentiality, Integrity, and Availability aspects of the Application's Business Requirements. | % of Applications per Categorization | 3 | |
I.2.2 | Business Impact Assessment Process | A process that identifies and documents the Line of Business (LoB) supported by the Application and how the LoB will impacted; identifies and documents core Components needed to maintain functionality of the Application (both Software and Hardware Components); identifies and documents the length of time the system can be down before the LoB is negatively impacted; identifies and documents the LoB's tolerance for the loss of data. | Service Level Agreements per Component per Application (in Hrs) | 4 | |
I.3.1 | Secure Systems Development Process | A documented Standards and Process for System (Software) Development that includes Security Best Practices; a Security Training Program for Developers, Managers, and Architects are required; Quality Management program is documented that includes planning, change management, and security testing (misuse cases, fuzzing, dynamic scanning); Separation of development, test, and operational facilities, where all facilities have been accredited; documented Secure Code Practices (common framework usage for common security functions; language specific secure coding requirements); implementation of source code repositories that adhere to role-based access procedures and logging enabled. | % of Applications per Categorization that have a separate test environment | 5 | |
Table 1. Example of mapping NIST Controls with the Initiation phase of the SDLC.
(Watch more : 5 Implications of HTML 5 on Security)
Conclusion
The most effective way to help your Organization to implement the Risk Management Framework (RMF) is to consider and include the increasing reliability on and growing complexity of Applications. Applications and the technologies used to develop and deploy to are constantly changing, and with this constant change the risk environment is also changing, resulting in the need to reduce risks before the Applications escape into the environment. With the inclusion of the SDLC as part of the RMF the following return on investment is provided:
- Early identification and mitigation of weaknesses, vulnerabilities, and misconfigurations resulting in lower cost of mitigation and remediation (Ponemon, 2010).
- Awareness of potential integration and engineering issues resulting from mandatory controls, resulting in lower cost of integrating and engineering into the Application altnerate compensating controls.
- Identification of shared controls and reusability security frameworks and application programming interfaces, resulting in lower development costs and reduction in impact to development schedule while simultanously improving the overall security of Application in the marketplace.
- Ability to allow Executive management to make key decisions in a comprehensive Risk Management strategy, resulting in reduced risk to the Organization.
References
- Kissel, R., et al. (2008). NIST SP 800-64 Rev 2: Security Considerations in the System Development Life Cycle. http://csrc.nist.gov/publications/PubsSPs.html.
- Ross, R. (2011). NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. http://www.nist.gov/manuscript-publication-search.cfm?pub_id=908030.
- Swanson, M. (2001). NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems. http://infohost.nmt.edu/~sfs/Regs/sp800-26.pdf.
- Guttman, B. and Roback, E. (2006). Special Pub 800-12 -- An Introduction to Computer Security: The NIST Handbook. http://csrc.nist.gov/publications/nistpubs/800-12/.
- Challey, D. (2009). Enterprise Application Security - GE's approach to solving root cause and establishing a Center of Excellence. https://www.owasp.org/index.php/Enterprise_Application_Security_-_GE's_approach_to_solving_root_cause_and_establishing_a_Center_of_Excellence.
- Ponemon. (2010). Fifth Annual US Cost of Data Breach, January 2010. Retrieved from http://www.ponemon.org/data-security.
More: Want to become a speaker and address the security community? Click here
Comments