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:

  1. 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).

 

  1. 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.

 

  1. 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
  % of Applications per Requirement

1

System Concept Review that verifies the   concept is in line with Organization's objectives and budgetary constraints

  Performance requirements that has addressed all Security Requirements

  Enterprise Architecture alignment that aligns with IT standards and LoB   requirements, as well as Security alignment to enable LoB by meeting Security   Requirements with appropriate Security Services

  Risk Management review that provides a Risk view of the System that aligns   with the Organization's level of acceptance

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)
  Number of Components per Application by Type, i.e. Software, Hardware
  Number of Applications per LoB by Categorization

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
  % of Completed Training Requirement

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:

  1. Early identification and mitigation of weaknesses, vulnerabilities, and misconfigurations resulting in lower cost of mitigation and remediation (Ponemon, 2010).
  2. 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.
  3. 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.
  4. Ability to allow Executive management to make key decisions in a comprehensive Risk Management strategy, resulting in reduced risk to the Organization.

References

 

More:  Want to become a speaker and address the security community?  Click here    

E-mail me when people leave their comments –

You need to be a member of CISO Platform to add comments!

Join CISO Platform