Secure and Resilient Software Development

• Software is ubiquitous, even in places you wouldn’t imagine.
• Software is so seamlessly interwoven into the fabric of modern living that it fades into the background without notice.

• Software is not used just by a small cross section of the modern-day society. But, The entire population depends on Software. Airlines, banks, telecommunication companies, hospitals, supermarkets, gas stations, voting infrastructures, and countless other institution rely on software.
• At this stage of technological innovation, we have come to realize that software must not only function properly but also be available to us at all times and in all places so that we can continue to thrive in the digital ways of life to which we’ve grown accustomed.
• While we'd like to believe that software is as reliable as it need to be, reality proves us wrong every time. We’ll examine what makes software fragile, brittle, and resistant to reliability and resilience, What we refer to as software resilience is an adaption of the National Infrastructure Advisory Council (NIAC) definition infrastructure resilience.
• Software resilience is the ability to reduce the magnitude and/or duration of disruptive events. The effectiveness of a resilient application or infrastructure software depends on its ability to anticipate, absorb, adapt to ,and/or rapidly recover from a potentially disruptive event.

• A vulnerability, in the context of software, is a defect in the implementation that opens a pathway for an attacker with the right set of skills to exploit the defect and cause the software to behave in ways the software developer never anticipated.
• A vulnerability in computer security, is a weakness which allows an attacker to reduce a system’s information assurance.
• Vulnerability is the intersection of two elements:
  • a system susceptibility or flaw
  • attacker access to the flaw.

• Just as software is everywhere,flaws in software are everywhere, too. Flaws in software can threaten the security and safety of the systems on which they operate. These flaws are not present just in the traditional computers, but also in critical devices that we use, such as our cellphones, cars and hospital equipments.
• Example: IPhone owners can use the optional passcode lock feature of their phone to protect all the confidential documents and personal information on it. However, anyone who has obtained a protected stolen iPhone can easily by pass the lock and gain access to all the persona data on the phone just by double clicking the home button on the phone. Apple has fixed this issue on later version of the iPhone operating system.

• In 2005,several thousand Toyota Prius cars, fuel-efficient hybrid vehicles, had to recalled for safety purpose. In February 2010 the company announced a recall of 400,000 Priuses for a problem that involved that cars’ antilock brakes.According to Toyota Company, it was a software glitch. Subsequently, Toyota extended the recalls to cover millions of its vehicles, including addressing an apparent software glitch that did cause sudden acceleration.

• Programmers writing custom code for corporation to use internally, programmers working at software development companies that produce commercial programs and programmers working in the public domain, all suffer from the same fundamental problem: They were not taught how to write secure and resilient programs.

• Organizations across the globe spend millions of dollars on securing their software infrastructure every year. they spend on:
  • Detecting existing vulnerabilities in the software they already own.
  • Finding ways to reduce the risks associated with using it.
  • Rewriting software, whether to fix a problem or fundamentally change what the software does.
  • Additionally, losses in productivity when an application or a system goes down also results in direct or indirect losses to the business.

• Information Security is the ability to protect the confidentiality, integrity, and availability of the information.
• Confidentiality is the goal of being assured that information is protected from being accessed by unauthorized users.
• Integrity is concerned with implementing controls to ensure that information cannot be modified without proper authorization and that stored information cannot be tampered with. It is applicable for information at rest or when in transit.
• Availability is making sure that the information is made available to authorized users whenever they need it.
• Integrating security into the software development life cycle is the key to eliminate current problems once and for all.

Here is the Institute of Electronics and Electrical Engineering (IEEE) Definition of requirements:

• Functional Requirement: A system or software requirement that specifies a function that a system /software or system/software component must be capable of performance. These are software requirements that define system behavior and the fundamental process that the system’s software and hardware components perform on inputs to produce output.
• Nonfunctional requirements: A software requirement that describes not what he software will do but how the software will do it.

• Software testing, which focus only on functionality testing for user acceptance, can uncover errors(bugs or flaws) about how the software operates.
• Resilience tests verify that the function, designed to meet a nonfunctional requirement or service, operate as expected. It also validates that the implementation of those functions is not flawed or haphazard.

Availability levels:

• High availability: The system or application is available during specified operating hours with no unplanned outages.
• Continuous operations: The system or application available 24 hours a day, 7 days a week ,with no scheduled outages.
• Continuous availability: The system or application available 24 hours a day, 7 days a week, with no planned or unplanned outages.

• Capacity planning is made far simpler when runtime environments can be changed on the fly to accommodate changes in user traffic, changes in hardware, and other runtime related considerations.

• Efficiency refers to the degree that a system uses scarce computational resources, such as CPU cycles, memory, disk space, buffers and communication channels.
• Efficiency can be characterized using these dimensions:
  • Capacity
  • Degradation of service

• Interoperability is the ability of a system to work with other systemS or software, without any special effort on the part of the user, the implementers, or the support personnel.
• Interoperability can only be implemented when everyone involved in the development process adheres to common standards.
• Interoperability requirements should dictate what standards must be applied to these elements, and how the designers and developers can get their hands on them to enable compliant application software.

• Manageability allows support personnel to move the application around available hardware as needed or run the software in virtual machine.
• Manageability features require designers and developers to build software as a highly cohesive and loosely coupled.

• Cohesion is increased when the methods of a software module have many common aspects, are focused on a single subject, and can be carried out across a variety of unrelated sets of data.
• Low cohesion leads to the following problems:
  • difficulties in understanding the modules.
  • difficulties in maintaining a system.
  • difficulties in reusing a module.

• Strong coupling happens when a dependent class contain a pointer directly to a concrete class that offers the required method.
• Loose coupling occurs when dependent class contains a pointer only to an interface.

• Software maintenance refers to the modification of a software application after delivery in order to correct faults, improve performance or adapt the product to modified environment.
• Software maintenance is an expensive and time-consuming aspect of development.
• Software Maintenance Maturity Model(SMmm) was developed to address the assessment and improvement of the software maintenance function by proposing a maturity model for daily software maintenance activities.

• Performance requirements generally address three areas:
  • Speed of processing a transactions
  • Volume of simultaneous transactions
  • Number of simultaneous users

• Portability is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed.
• Portability is a key issue for development cost reduction, and sufficient time must be allowed to determine the optimal languages and development environments needed to meet the requirement without the risk of developing different environment.

• Many privacy controls are implemented as security controls.
• privacy include non-security aspects of data collection and use.
• Privacy is concerned with the degree of information disclosure.
• The principles for collecting information:
  • Notice/ Awareness: websites must inform the users about how it collects and handles user information.
  • Choice/Consent: Users of websites must have control over how their personally identifying information is used .
  • Access/Participation: Users must be able to review, correct, and in some cases delete personally identifying information on a particular website.
  • Security /Integrity: websites must do more than reassure users that their information is secure with a ”feel_good” policy statement.

• Recoverability is related to reliability and availability, but it is extended to include requirements on how quickly application must be restored in the event of a disaster, unexpected outage, or failure of a dependent system.

• Reliability may be defined in several ways:
  • The capacity of a device or system to perform as designed.
  • The resistance to failure of a device or system.
  • The ability of a device or system to perform a required function under stated conditions for a specified of time.
  • The probability that a functional unit will perform its required function for a specified interval under stated condition.
  • The ability of something to fail well.

• Scalability is the ability of a system to grow in its capacity to meet the the rising demand for its service offered and its related to capacity NFRs.
• System Scalability criteria might include the ability to accommodate increasing number of:
  • Users
  • Transactions per second
  • Number of database that can run and provide results simultaneously

• Security NFRs are needed to preserve the goals of confidentiality, integrity and availability.
• Here are just a few objectives that are needed for software that’s expected to be secure and resilient:
  • Ensure that users and client applications are identified and that their identities are properly verified.
  • Ensure that all access or modify data are logged and tracked.
  • Ensure that users' and clients' applications can only access data and service for which they have been properly authorized.
  • Ensure that communications and data are not intentionally corrupted.
  • Ensure that confidential communications and data are kept private.
  • Ensure that application can survive an attack, or fail securely.

• Serviceability refers to the ability of application support personnel to install, configure and monitor computer software, identify expectations of faults, debug or isolate faults to perform root-cause analysis and provide hardware or software maintenance to aid in solving a problem and restoring the software to service.
• Some examples of requirements that facilities serviceability are:
  • Help desk notification of exceptional events
  • Network monitoring
  • Standardized documentation tools and processes
  • Event logging
  • Logging of program state
  • Procedure entry and exit with input and return variable states

• Different methodologies dictate different documentation techniques for requirements gathering and analysis.Unified Modeling Language and Rational Unified Process fans are familiar with use cases to capture functional requirements but may find that they are not well suited for capturing NFRs.
• Nonfunctional requirements may be documented in any form that suites the development process in use but should be standardized across all development terms and should be include in all analysis and design documentations.

• The only reliable way to ensure that software is constructed secure and resilient is by integrating a security and resilience mindset and process throughout the entire software development life cycle(SDLC).
• The security processes is often just “common sense” improvements and any organization can and should adopt them into its existing environment.
• the following figure provides a high-level overview of the fundamental security and resilience processes that should be integrated into the various SDLC phases.

• Here you will find guidance that you should consider implementing for each phase of development:
  • Requirements gathering and analysis
  • System detail designs
  • Application coding and reviews
  • Testing steps
  • Deployment steps

• The key activities during the requirements gathering and analysis phase are intended to map out and document the nonfunctional requirements.
• To be effective, business systems analyst and systems designers should be sure they are very familiar with the environment in which they operating, by reviewing and maintaining their knowledge about:
  • Organizational security policies and standards
  • Organizational privacy policy
  • Regulatory requirements
  • Other relevant industry standards

• Threat modeling and design reviews are the two major resilience processes.
• There are two classes of vulnerabilities:
  • design-related vulnerabilities
  • implementation-related vulnerabilities
• Detailed threat modeling is an excellent way to determine the technical security posture of an application to be developed or under development. It consist of four key steps:
  • Functional decomposition
  • Categorizing threats
  • Ranking threats
  • Mitigation planning

• Functional Decomposition is typically performed using data flow diagrams.
• The key is to understand the boundaries of untrusted and trusted components.

STRIDE is a framework developed by Microsoft for classifying threats. The different threat categories used are:

• Spoofing of user identity: one example is illegally accessing and then using another user’s authentication information.
• Tampering: Threats in this area involve the malicious modification of data
• Repudiation: Threats in this area associated with users who deny performing an action without other parties having any way an to prove. Non-repudiation refers to the ability of a system to counter repudiation threats.
• Information disclosure: Threats in this area involve the exposure of information to individuals who are not supposed to have access to it.
• Denial of service: Denial of service(DOS) attacks deny service to valid users, You must protect against certain types of DoS threats simply to improve system availability and reliability.
• Elevation of privilege: Include those in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself.

• Ranking potential threats for a software system requires a fair amount of subjective judgment. DREAD is a model developed by Microsoft.
• Threats are ranked by asking the following question:
  • Damage potential: How great is the damage if the vulnerability is exploited?
  • Reproducibility: How easy is it to reproduce the attack?
  • Exploitability: How easy is it to launch an attack?
  • Affected users: As a rough percentage, how many users are affected?
  • Discoverability: How easy is it to find the vulnerability?

• With a list of ranked threats, you can document a high-level mitigation plan by mapping them to the potential vulnerability in the software system.

• Threat modeling and design reviews can leverage commercial off-the-shelf tools, custom in-house software, or eve simple checklists. Personnel must use their best judgment based on the environment, the organizational structure and existing processes and practices.

see the following figure for the major steps in the design phase.

• Activities in this phase often generate implementation-related vulnerabilities.
• Static analysis and peer review are two key processes to mitigate or minimize these vulnerabilities.

• It involves the use of automated tools to find issues within the source code itself:
  • Bug finding
  • Style checks
  • Type checks
  • Security vulnerability review

• A peer review is far more time-consuming than automated analysis, but it is an excellent control mechanism to ensure the quality and security of the code base.
• Developers review each other's code and provide feedback to the owners of the different modules so that they can make appropriate changes to fix the flaws discovered during the review.

• Unit testing is another key process that many organizations fail to perform regularly but is important from security and resilience perspective.
• Unit testing helps to prevent bugs and flaws from reaching the testing phase.

The following figure shows the diagram of the security activities in the development phase.

• The test phase is critical for discovering vulnerabilities that were not discovered and fixed earlier.
• The security team uses all the assumptions and business processes captured to create several security test cases.
• The software is loaded and operated in the test environment and tested against each of the test cases.
• The software is loaded and operated in the test environment and tested against each of the test cases.
• Dynamic analysis consist of using automated tools to test for security vulnerabilities.
• These tests are iterative in nature and result in a list of vulnerabilities that are then errors and sends the ranked for and prioritized.
• See the following figure for a diagram of the security steps in the test phase of the SDLC.

• The deployment phase is the final phase of the SDLC.
• Deployment is a key part of changes advisory board(CAB). A CAB offers the multiple perspectives necessary to ensure good decision making.
• A CAB is an integral part of defined change management process designed to balance the need for change with the need to minimize inherent risks.
• During the deployment phase:
  • Security subject-matter experts perform a final security review to ensure that the security risks identified during all the previous phases have been fixed or have a mitigation plan in place.
  • The development team coordinates with the release management and production support teams to create an application security monitoring and response plan.

See the following figure for the security activities in the deployment phase of the SDLC.

• Security training plays an important role in improving the overall security and resilience of developed software.
• Training should be a prerequisite for anyone who has a role in the software development environment.

• Entire network architectures consisting of firewalls, routers and intrusion detection and prevention devices, limited outside traffic to only supported protocols and services, while all others were blocked or prevented from entering the network.
• Port 80 and Port 443(SSL) on corporate firewalls are open wherever there's a Web server or Web service available to public users or extranet. Since, Web traffic is never blocked, attacks are structured and executed directly on Web applications that accept and respond to user inputs on Web from fields.
• Web security is a universal programming problem, not a local operations or networking problem.

The following figure shows an illustration of the problem (Hole in the firewall).

• A simple definition: Security perimeter is the border between the assets we want to protect and the outside world.
• Physical security controls are meant to prevent and/or deter attackers from accessing a private property without authorization.
• We can consider implementing several measures:
  • A licked gate
  • A fence or high wall around the property
  • A security guard at the entrance
  • Security cameras
  • Automated security monitoring and alarm systems
• This concept of a trusted and secured zone and security checked for whatever enters that zone is applicable to software and networks of today's business.

• The application has control over the elements that are inside the application perimeter:
  • Web server
  • application server
  • Database server
• The application has no control over the elements outside the application perimeter:
  • Web browsers
  • other applications
  • External Databases

• A simple definition of an Attack Surface is all possible entry points that an attacker can use to attack the application or system under consideration.
• In the case of Web application, the attack surface is defined by:
  • All the Web pages the attacker can access
  • Every point at which the attacker can interact with the application
  • Every function provided by the application
• The exact attack surface depends on who the attacker is (internal VS external presence):
  • Malicious application users may again access to unauthorized functionality
  • External attackers usually have limited access(unauthenticated areas of the application)

• The attack surface is usually larger than a typical application developer or software architect imagine
• In the case a Web application, the following techniques are often used:
  • Crawl every page of the application(using an automated tool)
  • Identify all the available functionality:
    • Follow every link
    • Fill every form with valid/invalid data and submit
  • Look for the points where the user can supply information to the application:
    • GET requests with query strings parameters
    • POST requests generated by forms
    • HTTP headers
    • Cookies
    • Hidden parameters

• Sometimes attackers target the implementation rather than the actual theoretical weakness in the system.
• Side channel attacks, are critical area for designers and developers who are designing and deploying secure hardware and software systems.
• A simple example of a side channel attacks is the “timing attack”. If a person is asked to pick and retrieve different items, one at a time, at a supermarket. it’s possible measure the time it takes for each item to be brought back to determine the relative positions of the different areas of the store and to guess the location of other related items in the store.

• Following are 10 principles and best practices, adapted from Open Web Application Security Project(OWASP):
  1. Apply defense in depth
  2. Use a positive security model
  3. Fail securely
  4. Run with least privilege
  5. Avoid security by obscurity
  6. Keep security simple
  7. Detect intrusions
  8. Don’t trust infrastructure
  9. Don’t trust services
  10. Establish secure defaults

• The principle of defense in depth emphasizes that security is increased when it is implemented as a series of overlapping layers of controls and countermeasures that provide prevention, detection, and response.
• The following figure from Cisco’s Unified Contact Center Enterprise (CCE) documentation, illustrates the concept of defense in depth.

• The positive security model that is often called whitelisting defines what is allowable and rejects everything that fails to meet the criteria.
• The positive model should be contrasted with a blacklist security model, which defines what is disallowed, while implicitly allowing everything else.
• The positive security model can be applied to a number of different application security areas:
  • It should be applied to every field of input(hidden or not)
  • Validation routines or frameworks should be implemented to specify the characteristic of input that allowed, as opposed to trying to filter out bad input.
  • With access controls, the positive model will allow only access to specific authorized resources or functions.

• Major types of errors require special attention:
  • Exceptions that occur in the processing of a security control itself
  • Exceptions in code that are not “security-relevent”
• There are three possible outcomes from a security mechanism:
  • Allow the operation
  • Disallow the operation
  • Exception
• you should design your security mechanism so that failure will follow the same execution path as disallowing the operation.

• The principles of least privilege recommends that user accounts have the least amount of privilege required to perform their basic business processes.
• This encompasses user rights and resource permissions such as:
  • CPU limits
  • Memory
  • Network permissions
  • File system permissions

• Security by obscurity describes an attempt to maintain the security of a system or application based on the difficulty in finding or understanding the security mechanism within it.
• An example of security by obscurity is a cryptographic system in which the developers wish to keep the algorithm that implements the cryptographic functions a secret rather than keeping the keys a secret and publishing the algorithm so that security researchers can determine if it is bullet-proof enough for common security uses.

• Avoid complex approaches to coding with what would otherwise be relatively straightforward and simple code for someone to read and understand.
• Break security functions and features down into these discrete objectives:
  • Keep services running and information away from attackers-related to deny access by default.
  • Allow the right users access to the right information –related to least privilege.
  • Defense every layer as if it were the last layer of defense-related to defense in depth.
  • Keep a record of all attempts to access information(logging)
  • Compartmentalize and isolate resources

• Detecting intrusions in application software requires three elements:
  • Capability to log security-relevant events
  • Procedures to ensure that logs are monitored regularly
  • Procedures to respond properly to on an intrusion once it has been detected

• Sometimes you can detect a problem with software by reviewing the log entries that you that you can’t detect at runtime, but you must log enough information to make that possible and useful.
• The logging functionality in the application should also provide a method of managing the logged information to prevent tampering or loss.

• If a security analyst is unable to parse through the event logs to determine which events are actionable, then logging events provide little to on value.

• Detecting intrusion is important because otherwise you give the attacker unlimited time to perfect an attack.
• If you detect intrusion perfectly, then an attacker will get only one attempt before he is detected and prevented from launching more attacks.

• Relying on a security process or function that may or may not be present is a sure way to have security problems.

• Make sure that your application’s security requirements are explicitly provided through application code or explicit invocation of reusable security functions provided to application developers to use for the enterprise.

• Services can refer to any external system. Implicit trust of externally run system is not warranted. All external systems should be treated in a similar fashion.
• example: a loyalty program provider provides data, used by Internet banking, providing the number of reward points and a small list of potential redemption items. Within your program that obtains this data, you should check the results to ensure that it is safe to display to end users, and that reward points are a positive number and not improbably large.

• Secure by defaults means that the default configuration setting are the most secure setting possible friendly.
• Example: password aging and complexity should be enabled by default. Users may be allowed to turn these two features of to simplify their use of the application and increase their risk analysis and policies, but doesn’t force them into an insecure state by default.

• The converges of Practices and NFRs is so dense, applying a security best practice will lead you to solving other non-security-related issues that your development teams and operations support personnel will most appreciate.

• Recommendations for the design phase are shown in the following table:

• Misuse Case: A business process modeling tool used in the software development business. The term misuse case is derived from use case, meaning it is the inverse of a use case.
• Use case model identifies regular uses of the application and is useful to model unorthodox or malicious uses of the application. For security architects and software testers, a use case model provides direct security value.

• In most software development projects, time and budget are fixed values, and the introduction of security and resilience requirement is generally not well received by software development teams.
• The best place to introduce the security design and architecture review is when the team are engaged in the functional design and architecture review of the software.
• Generating a security plan from the review is a good start for documenting the security design and use it as a check-and-balance guide during and after development.

• Threat modeling includes determining the attack surface of the software by examining its functionality for trust boundaries, entry points, data flow, and exit point.
• Threat modeling is useful for ensuring that the design complements the security objectives, making trade-off and prioritization-of-effort decisions, and reducing the risk of security issues during development and operations.
• Risk modeling of software can be accomplished by ranking the threats as they pertain to your organization’s business objectives, compliance and regulatory requirements, and security exposure.
• Threat modeling is an iterative technique used to identify the threats to the software under construction.
• Attack surface analysis, is a subset of threat modeling and can be performed when generating the software context to zero in on the parts of the software that are exposed to nontrusted users.
• The following information should be included in threat-model documentation:
  • A diagram, and an enumeration and description of the elements in your diagram.
  • A threat analysis, since that is core of the threat model.
  • For each mitigated threat that you identify in threat analysis, the bug or defect number associated with the mitigate plan.
  • A one- or two-paragraph description of your software components and what they do.
  • Confirm that threat model data and associated documentation is stored using the document controls system used by the development team.

• Risk analysis considerations include:
  • Threats and vulnerabilities that exist in the project’s environment or result from interaction with other systems.
  • Code that was created by external development groups in either source or project form.
  • Threat models should include all legacy code if the project is a new release of an existing program.
  • A detailed privacy analysis to document your project’s key privacy aspects. Important issues to consider include:
    • What personal data is collected?
    • What is the compelling customer value proposition and business justification?
    • What notice and consent experiences are provided?
    • How is unauthorized access to personal information prevented?

• Here are some rules of thumb to use while performing your threat modeling:
  • If the data has not crossed a trust boundary, you do not really care about it.
  • If the threat requires that the attacker is already running code on the client at your privilege level, you don’t care about it.
  • If your code runs with any elevated privileges, you need to be concerned.
  • If your code invalidates assumptions made by other entities, you need to be concerned.
  • If your code listens on the network, you need to be concerned.
  • If your code retrieves information from the interne, you need to be concerned.
  • If your code deals with data that came from a file, you need to be concerned.
  • If your code is marked as safe for scripting or safe for initialization, you need to be concerned.

• Assurance that users and client applications are identified and that their identities are properly verified.
• Assurance that users and client applications can only access data and services for which they have been properly authorized.
• Ability to detect attempt intrusions y unauthorized people and client applications.
• Assurance that unauthorized malicious programs do not infect the application or component.
• Assurance that communications and data are not intentionally corrupted.
• Assurance that parties to interactions with the application or component cannot later repudiate those interactions.
• Assurance that confidential communications and data are kept private.
• Assurance that applications can survive attack, or operate in a degraded mode.

• Secure design patterns are descriptions or templates for a general solution to a security problems.
• Secure design patterns are meant to eliminate the accidental insertion of vulnerabilities into code or to mitigate the consequences of vulnerabilities.
• Secure design patterns are categorized according to their level of abstraction, as described below:
  • Architectural-level patterns:Focus on the high-level allocation of responsibilities among different components of the system and define the interactions among those high-level components.
• Design-level patterns:Describe how to design and implement elements of a high-level system component.
• Implementation-level patterns: patterns in this class are usually applicable to the implementation of specific functions or methods in the system.

• A fundamental principle of Web application design is the separation of processing and control across multiple dedicated server infrastructures that cross a number of network domains.
• Web applications are best suited for operating on in infrastructure that consist of Web server(s), application server(s), and database sever(s).
• The three-tire model is especially helpful for implementing security controls because it provides loose coupling that enables implementing security controls in exactly the places where they’ll do the most good while supporting the principle of defense in depth. Three or n-tire architectures also offer following advantages:
  • Centralization permits IT to control and secure programs and servers using an already-accepted, mainframe-life environment that is scalable, predictable, and easily monitored.
  • Reliability is enhanced.
  • Scalability is easier because servers or processors can be added to achieve acceptable levels of performance.
  • Flexible, well-defined software layers permit the highest degrees of IT responsive to changing business needs.
  • Existing mainframe services can be reused through the virtue of a flexible data layer.
  • Systems based on open industry standards allow companies to incorporate new technologies into the operation rapidly, without concern about interoperability problems that exist in products based on proprietary approaches.

• The Microsoft Developers Network(MSDN) covers most security and resilience aspects of the architecture and design stage of the SDLC, including the following areas:
  • Authentication
  • Authorization
  • Configuration Management
  • Sensitive Data
  • Session Management
  • Cryptography
  • Parameter Manipulation
  • Exception Management
  • Auditing and logging

• How do security maturity models like Open SAMM and BSIMM it into this picture?
  • Both have done a great job cataloging, updating, and organizing many of the “rules of thumb” that have been used over the past few decades for investing in software assurance.

• The Open Software Assurance Maturity Model(SAMM) is an open framework developed to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.
• The resources provided by OpenSAMM will aid in:
  • Evaluating an organization's existing software security practices
  • Building a balanced software security program in well-defined iterations
  • Demonstrating concrete improvements to a security assurance program
  • Defining and measuring security-related activities within an organization
• OpenSAMM starts with the core activities that should be present in any organization that develops software:
  • Governance: Centered on the processes and activities related to how an organization manages overall software development activities.
  • Construction: Concerns the processes and activities related to how an organization defines goals and creates software within development projects.
  • Verification: is focused on the processes and activities related to how an organization checks and tests artifacts produced throughout software development.
  • Deployment: entails the processes and activities related to how an organization manages release of software that has been created.
• The three maturity levels for a practice correspond to:
  1. Initial understanding and ad hoc provision of the Practice
  2. Increase efficiency and/or effectiveness of the Practice
  3. Comprehensive mastery of the Practice at scale

• Strategy & Metrics (SM) involves the overall strategic direction of the software assurance program and instrumentation of processes and activities to collect metrics about an organization's security posture.

• Policy & Compliance (PC) involves setting up a security and compliance control and audit framework throughout an organization to achieve increased assurance in software under construction and in operation.

• Education & Guidance (EG) involves increasing security knowledge among personnel in software development through training and guidance on security topics relevant to individual job functions.

• Threat Assessment (TA) involves accurately identifying and characterizing potential attacks on an organization's software in order to better understand the risks and facilitate risk management.
• Security Requirements (SR) involve promoting the inclusion of security-related requirements during the software development process in order to specify correct functionality from inception.
• Secure Architecture (SA) involves bolstering the design process with activities to promote secure-by-default designs and control over technologies and frameworks on which software is built.

• Design Review (DR) involve inspection of the artifacts created from the design process to ensure provision of adequate security mechanisms and adherence to an organization's expectations for security.
• Code Review (CR) involves assessment of an organization's source code to aid vulnerability discovery and related mitigation activities as well as establish a baseline for secure coding expectations.
• Security Testing (ST) involves testing the organization's software in its runtime environment in order to both discover vulnerabilities and establish a minimum standard for software releases.

• Vulnerability Managemen involves establishing consistent processes for managing internal and external vulnerability reports to limit exposure and gather data to enhance the security assurance program.
• Environment Hardening involves implementing controls for the operating environment surrounding an organization's software to bolster the security posture of applications that have been deployed.
• Operational Enablement involves identifying and capturing security-relevant information needed by an operator to properly configure, deploy, and run an organization's software.

Each core practice area is further detailed with a defined level of maturity using the following structure:

• Objective: The Objective is a general statement that captures the assurance goal of attaining the associated Level.
• Activities: The Activities are core requisites for attaining the Level. Some are meant to be performed organization-wide and some correspond to actions for individual project teams.
• Results: The Results characterize capabilities obtained by achieving the given Level.

• Success Metrics: The Success Metrics specify example measurements that can be used to check whether an organization is performing at the given Level. Data collection and management are left to the choice of each organization, but recommended data sources and thresholds are provided.
• Costs: The Costs are qualitative statements about the expenses incurred by an organization attaining the given Level.

• Personnel: These properties of a Level indicate the estimated ongoing overhead in terms of human resources for operating at the given Level.
  • Developers Individuals performing detailed design and implementation of the software.
  • Architects:Individuals performing high-level design work and large-scale system engineering.
  • Managers: Individuals performing day-to-day management of development staff.
  • QA Testers: Individuals performing quality assurance testing and release verification of software.
  • Security Auditors: Individuals with technical security knowledge related to software being produced.
  • Business Owners: Individuals performing key decision making on software and its business requirements.
  • Support Operations: Individuals performing customer support or direct technical operations support.

• Related levels: These properties of a Level indicate the estimated ongoing overhead in terms of human resources for operating at the given Level.

• Since the 12 Practices are each a maturity area, the successive objectives represent the “building blocks” for any assurance program.
• OpenSAMM is designed for improving an assurance program in phases by:
  • Selecting security Practices to improve in the next phase of the assurance program.
  • Achieving the next objective in each Practice by performing the corresponding Activities at the specified Success Metrics.
• Using interval scorecards is encouraged for several situations:
  • Gap analysis: Capturing scores from detailed assessments versus expected performance levels.
  • Demonstrating improvement: Capturing scores from before and after an iteration of assurance program build out.
  • Ongoing measurement: Capturing scores over consistent time frames for an assurance program that is already in place.

• A tool to help people understand and plan a software security initiative based on the practices the BSIMM developers observed when developing the Software Security Framework.
• The project's primary objective was to build a maturity model based on actual data gathered from nine large-scale software development initiatives.
• A maturity model is appropriate because improving sotware security almost always means changing the way an organization works—something that doesn't happen overnight. The model is divided into 12 practices, falling under four categories:
  • Governance
  • Intelligence
  • Software security development life cycle(SSDL) touch points
  • Deployment

• The BSIMM Software Security Framework (SSF) is shown in the following Figure.

• Governance includes those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.
• In the governance domain the strategy and metrics practice encompasses planning, assigning roles and responsibilities, identifying software security goals, determining budgets, and identifying metrics and gates.
• The compliance and policy practice focuses on identifying controls for compliance regimens such as PCI and HIPAA, developing contractual control setting organizational software security policy, and auditing against that policy.
• Training has always played a critical role in soft- ware security because software developers and architects often start with very little security knowledge.

• Intelligence includes those practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization.
• Attack models capture information used to think like an attacker: threat modeling, abuse-case development and refinement, data classification, and technology-specific attack patterns.
• The security features and design practice are charged with creating usable security patterns for major security controls, building middle-ware frameworks for those controls, and creating and publishing other proactive security guidance.
• The standards and requirements practice involves eliciting explicit security requirements from the organization, building standards for major security controls, creating security standards for technologies in use, and creating a standards review board.

• SSDL touch-points include those practices associated with analysis and assurance of particular software development artifacts and processes.
• The SSDL touchpoints domain:
  • Architecture analysis encompasses capturing software architecture in concise diagrams, applying lists of risks and threats, adopting a process for review and building an assessment and remediation plan for the organization.
  • The code review includes use of code review tools, the development of customized rules, profiles for tool use by different roles, manual analysis, and tracking/measuring results.
  • The security testing practice is concerned with prerelease testing including integrating security into standard quality assurance processes. Security testing focuses on vulnerabilities in construction.

• Deployment includes those practices that interface with traditional network security and software maintenance organizations.
• In Deployment domain:
  • The Penetration testing focuses on vulnerabilities in final configuration and provides direct feeds to defect management and mitigation.
  • The Software environment practice concerns itself with operating system and platform patching, Web application firewalls, installation and configuration documentation, application monitoring, change management, and ultimately code signing.
  • The Configuration management and vulnerability management practice is concerned with patching and updating applications, version control, defect tracking and remediation, and incident handling.

1. Attain a common understanding of direction and strategy.
2. Managers must ensure that everyone associated with creating, deploying, operating, and maintaining software understands the written organizational software security objectives.
3. Leaders must also ensure that the organization as a whole understands the strategy for achieving these objectives.
4. A common strategic is essential for effective and efficient program.

1. Publish process (roles, responsibilities, plan): evolve as necessary. The process for addressing software security is broadcast to all participates so that everyone knows the plan.
2. Create evangelism role/internal marketing: In order to build support for software security throughout the organization, the SSG plays an evangelism role, The SSG might give talks for internal groups, extend invitations to outside speakers, author white papers for internal consumption, or create a collection of papers, books, and other resources on an internal website.
3. Educate executives: Executives learn about the consequences of inadequate software security and the negative business impact that poor security can have. They also learn what other organizations are doing to attain software security.
4. Identify gate locations, gather necessary artifacts: The software security process will eventually involve release gates at one or more points in the software development life cycle (SDLC) or SDLCs. Importantly at this stage, the gates are not enforced.
5. identify metrics and drive initiative budgets with them: The SSG chooses the metrics it will use to define software security initiative progress. These metrics will drive the initiative's budget and allocation of resources. Metrics also allow the SSG to explain its goals in quantitative terms.

1. Publish data about software security internally: The SSG publishes data internally on the state of software security within the organization with the philosophy that sunlight is the best disinfectant. If the organization's culture promotes internal competition between groups, this information adds a security dimension to the game.
2. Enforce gates with measures and track exceptions: Gates are now enforced: In order to pass a gate, a project must either meet an established measure or obtain a waiver. Even recalcitrant project teams must now play along. The SSG tracks exceptions.
3. Create or grow social network/satellite system: The satellite begins as a collection of people scattered across the organization who show an above-average level of security interest or skill.
4. Require security sign-off: The organization has a process for risk acceptance and accountability The prior to release.

1. Use internal tracking application with portfolio view: The SSG uses a tracking application to chart the progress of every piece of software in its purview. The application records the security activities scheduled, in progress, and completed. It holds results from activities such as architecture analysis, code review, and security testing.
2. Run external marketing program: The SSG markets itself outside the organization to build external support for the software security initiative.

1. Know all regulatory pressures and unify approach. The SSG creates a unified approach that removes redundancy from overlapping compliance.
2. Identify personally identifiable information (PII) obligations. The SSG takes a lead role in identifying Pll obligations stemming from regulation, customer demand, and consumer expectations. It uses this information to promote best practices related to privacy.

1. create policy. The policy provides a unified approach for satisfying the list of external security drivers. The SSG policy documents are sometimes focused around major compliance topics such as the handling of personally identifiable information or the use of cryptography.

1. Identify P11 data in systems: The organization identifies the kinds of PII stored by each of its systems. When combined with the organization's PII obligations, this inventory guides privacy planning.
2. Require security sign-off for compliance-related risk: The organization has a formal process for risk acceptance. The risk acceptor signs off on the state of the software prior to release.
3. Implement/track controls for compliance: The organization can demonstrate compliance with applicable regulations because its practices are aligned with the control statements developed by the SSG. The SSG tracks the controls, shepherds problem areas, and makes sure auditors are satisfied.
4. Paper all vendor contracts with SLAB compatible with policy: Vendor contracts include a service-level agreement (SLA) ensuring that the vendor will not jeopardize the organization's compliance story. Each new or renewed contract contains a standard set of provisions requiring the vendor to deliver a product or service compatible with the organization's security policy.
5. Promote executive awareness of compliance/privacy obligations: The SSG gains executive buy-in around compliance and privacy activities. Executives understand the organization's compliance and privacy obligations and the potential consequences for failing to meet those obligations.

1. Create regulator eye-candy: The SSG has the information regulators want. A combination of policy, controls, and artifacts gathered through the SSDL give the SSG the ability to demonstrate the organization's compliance story without a ire drill for every audit.
2. Impose Policy on Vendor: Vendors are required to adhere to the same information used internally. Vendors must submit evidence that their software security practice pass muster.
3. Drive feedback from SSDL data back to policy: Information from the SSDL is routinely fed back into the policy creation process. Polices are improved to find defects earlier or prevent them from occurring in the first place.

1. Provide awareness training: The SSG provides awareness training in order to promote a culture of security throughout the organization. Training might be delivered by members of the SSG, by an outside firm, by the internal training organization, or through a computer-based training system.
2. Include security resources in on boarding: The process for bringing new hires into the engineering organization includes a module on software security. The objective is to ensure that new hires enhance the security culture.
3. Establish SSG office hours: The SSG offers help to any and all comers during an advertised lab period or regularly scheduled office hours. By acting as an informal resource for people who want to solve security problems, the SSG leverages teachable moments and emphasizes the carrot over the stick.
4. Identify satellite through training: The satellite begins as a collection of people scattered across the organization who show an above-average level of security interest or skill.

1. Offer role-specific advanced curriculum (tools, technology stacks, bug parade): Software security training goes beyond building awareness and enables trainees to incorporate security practices into their work. The training is tailored to the role of trainees; trainees get information on the tools, technology stacks, or kinds of bugs that are most relevant to them.
2. Create/use material specific to company history: In order to make a strong and lasting change in behavior, training includes material specific to the company's history.
3. Require annual refresher: Everyone involved in making software is required to take an annual software security refresher course. The refresher keeps the staff up to date on security and ensures that the organization doesn't lose focus due to turnover.
4. Offer on-demand individual training: The organization lowers the burden on trainees and reduces the cost of delivering training by offering on-demand training for individuals.
5. Hold satellite training/events: The SSG strengthens its social network by holding special events for the satellite. The satellite learns about advanced topics or hears from guest speakers.

1. Reward progression through curriculum (certification or HR): Knowledge is its own reward, but progression through the security curriculum brings other benefits too. Developers and testers see a career advantage in learning about security.
2. Provide training for vendors or outsource workers: The organization offers security training for vendors and outsource providers. Spending time and effort helping suppliers get security right is easier than trying to figure out what they screwed up later on.
3. Host external software security events: The organization markets its security culture as a differentiator by hosting external security events. The organization as a whole benefits from putting its security credentials on display.

1. Build and maintain a top N possible attacks list: The SSG helps the organization understand attack basics by maintaining a list of the most important attacks. This list combines input from multiple sources: observed attacks, hacker forums, industry trends, etc.
2. Create data classification scheme and inventory: The organization agrees on a data classification scheme and uses the scheme to inventory its software according to the kinds of data the software handles. This allows applications to be prioritized by their data classification.
3. Identify potential attackers: The SSG identifies potential attackers in order to understand their motivations and capabilities. The outcome of this exercise could be a set of attacker profiles including generic sketches for broad categories of attackers and more detailed descriptions for noteworthy individuals.
4. Collect and publish attack stories: In order to maximize the benefit from lessons that do not always come cheap, the SSG collects and publishes stories about attacks against the organization.

1. Build attack patterns and abuse cases tied to potential attackers: The SSG prepares for security testing and architecture analysis by building attack patterns and abuse cases tied to potential attackers.
2. Create technology-specific attack patterns: The SSG creates technology-specific attack patterns to capture knowledge about technology-driven attacks.
3. Gather attack intelligence: The SSG stays ahead of the curve by learning about new types of attacks and vulnerabilities. The information comes from attending conferences and workshops, monitoring attacker forums, and reading relevant publications, mailing lists, and blogs.
4. Build internal forum to discuss attacks: The organization has an internal forum where the SSG and the satellite can discuss attacks. The forum serves to communicate the attacker perspective.

1. Have a science team that develops new attack methods: The SSG has a science team that develops new attack methods. The team works to identify and “defang” new classes of attacks before real attackers even know they exist.
2. Create and use automation to do what the attackers will do: The SSG arms testers and auditors with automation to do what the attackers are going to do.

1. Build/publish security features (authentication, role management, key management, audit/log, crypto, protocols): Some problems are best solved only once. Rather than have each project team implement all of its own security features, the SSG provides proactive guidance by building and publishing security for other groups to use.
2. Engage SSG with architecture: Security is a regular part of the organization's software architecture discussion. The architecture group takes responsibility for security the same way they take responsibility for performance, availability, or scalability.

1. Form review board or central committee to approve and maintain secure design: A review board or central committee approves and maintains secure design. The group formalizes the process for reaching consensus on design needs and security trade-offs.
2. Require use of approved security features and frameworks: Implementers must take their security features and frameworks from an approved list. There are two benefits: Developers do not spend time reinventing existing capabilities, and review teams do not have to contend with finding the same old defects in brand-new projects.

1. Create security standards: Software security requires much more than security features, but security features are part of the job as well. A standard might describe how to perform authentication using J2EE or how to determine the authenticity of a software update.
2. Create security portal: The organization has a central location for information about software security. Typically this is an internal website maintained by the SSG.
3. Translate compliance constraints to requirements: Compliance constraints arc translated into software requirements for individual projects.
4. Create secure coding standards: Secure coding standards help developers avoid the most obvious bugs and provide ground rules for code review. If the organization already has coding standards for other purposes, the secure coding standards should build on them.

1. Communicate standards to vendors: The SSG works with vendors to educate them and promote the organization's security standards. A healthy relation- ship with a vendor cannot be guaranteed through contract language.
2. Create a standards review board: The organization creates a standards review board to formalize the standards process and ensure that all stakeholders have a chance to weigh in. The board could operate by appointing a champion for any proposed standard.
3. Create standards for technology stacks: The organization uses standard technology stacks. A stack might include an operating system, a database, an application server, and a runtime environment for a managed language.
4. Identify open source in apps: The first step toward managing risk introduced by open source is to identify the open-source components in use. It is not uncommon to discover old versions of components with known vulnerabilities or multiple versions of the same component.
5. Create SLA boilerplate: The SSG works with the legal department to create standard SLA boilerplate for use in contracts with vendors and outsourcing providers. The legal department understands that the boilerplate helps prevent compliance or privacy problems.

1. Control open-source risk: The organization has control over its exposure to the vulnerabilities that come with using open-source components. Use of open source could be restricted to projects and versions that have been through an SSG screening process.

1. Perform security feature review: To get started with architecture analysis, center the analysis process on a review of security features.
2. Perform design review for high-risk applications: The organization learns about the benefits of architecture analysis by seeing real results for a few high-risk, high-profile applications.
3. Have SSG lead review efforts: The SSG cakes a lead role in performing architecture analysis in order to begin building the organization's ability to uncover design laws. Architecture analysis is enough of an art that the SSG needs to be proficient at it before they can turn the job over to the architects, and proficiency requires practice.
4. Use risk questionnaire to rank applications: At the beginning of the AA process, the SSG uses a risk questionnaire to collect basic information about each application so that it can determine a risk classification and prioritization scheme.

1. Define/use AA process: The SSG defines a process for performing architecture analysis and applies it in the reviews it conducts. The process includes a standardized approach for thinking about attacks and security properties.
2. standardize architectural descriptions (include data flow): The organization uses an agreed-on format for describing architecture, including a means for representing data low.
3. Make SSG available as AA resource/mentor: In order to build an architecture analysis capability outside the SSG, the SSG advertises itself as a resource or mentor for teams who ask for help conducting their own analysis. The SSG will answer architecture analysis questions during office hours, and in some uses might assign someone to sit side by side with the architect for the duration of the analysis.

1. Software architects lead review efforts: Software architects throughout the organization lead the architecture analysis process most of the time. The SSG might still contribute to architecture analysis in an advisory capacity or under special circumstances.
2. Drive analysis into standard architectural patterns: Failures identified during architecture analysis are fed back to the security design committee so the similar mistakes can be prevented in the future through improved design patterns.

1. Ensure that QA supports edge/boundary value condition testing: The QA team goes beyond functional testing to perform basic adversarial tests. They probe simple edge cases and boundary conditions. No attacker skills are required.
2. Share security results with QA: The SSG shares results from security reviews with the QA department. Over time, QA engineers learn the security mindset.

1. Integrate black box security tools into the QA process (including protocolfuzz0ing): The organization uses one or more black-box security testing tools as part of the quality assurance process. The tools are valuable because they encapsulate an attacker's perspective, albeit in a generic fashion.
2. Allow declarative security/security features to drive test: Testers target declarative security mechanisms and security features in general.
3. begin to build/apply adversarial security tests (abuse cases): Testing begins to incorporate test cases based on abuse cases provided by the SSG. Testers move beyond verifying functionality and take on the attacker's perspective.

1. Include security tests in QA automation: Security tests run alongside functional tests as part of automated regression testing; the same automation framework houses both. Security testing is part of the routine.
2. Perform fuzz testing customized to application APIs: Test automation engineers customize a fuzzing framework to the organization's APIs. They may begin from scratch or use an existing fuzzing toolkit, but customization goes beyond creating custom protocol descriptions or file format templates.
3. drive test with risk analysis results: Testers use architecture analysis results to fat their work.
4. Leverage coverage analysis: Testers measure the code coverage of their security tests in order to identify code that is not being exercised. Code coverage drives increased security testing depth.

1. Use external penetration testers to find problems: Many organizations are not willing to address software security until there is unmistakable evidence that the organization is not somehow magically immune to the problem.
2. Feed results to defect management and mitigation system: Penetration testing results are fed back to development through established defect management or mitigation channels, and development responds using their defect management and release process.
3. Use pen testing tools internally: The organization creates an internal penetration testing capability that makes use of tools. This capability can be part of the SSG, with the SSG occasionally performing a penetration test.
4. Provide penetration testers with all available information: Penetration testers, whether internal or external, are equipped with all available information about their target.
5. Periodic scheduled pen tests for app coverage: Test applications periodically according to an established schedule(which might be tied to the calendar or to the release cycle). The testing serves as a sanity check and helps ensure that yesterday's software isn't vulnerable to today's attacks.

1. Use pen testing tools internally: The organization creates an internal penetration testing capability that makes use of tools. This capability can be part of the SSG, with the SSG occasionally performing a penetration test.
2. Provide penetration testers with all available information: Penetration testers, whether internal or external, are equipped with all available information about their target.
3. Periodic scheduled pen tests for app coverage: Test applications periodically according to an established schedule (which might be tied to the calendar or to the release cycle). The testing serves as a sanity check and helps ensure that yesterday's software isn't vulnerable to today's attacks.

1. Use external penetration testers to perform deep dive (one-off bugs/fresh thinking): The organization uses external penetration testers to do deep-dive analysis for critical projects and to introduce fresh thinking into the SSG. These testers are experts and specialists.
2. Have SSG customize penetration testing (tools and scripts): The SSG either creates penetration testing tools or adapts publicly available tools so they can more efficiently and comprehensively attack the organization's systems.

1. Use application input monitoring: The organization monitors the input to software it runs in order to spot attacks. The SSG may be responsible for the care and feeding of the system. Responding to attack is not part of this activity.
2. Ensure that host and network security basics are in place: The organization provides a solid foundation for software by ensuring that host and network security basics are in place.

1. Use code protection: In order to protect intellectual property and make exploit development harder, the organization erects barriers to reverse engineering.
2. Publish installation guides created by SSDL: The software development life cycle requires the creation of an installation guide to help operators install and configure the software.
3. Use application behavior monitoring and diagnostics: The organization monitors the behavior of production software, looking for misbehavior and signs of attack.

1. Use code signing. The organization uses code signing for software published across trust boundaries: Code signing is particularly useful for protecting the integrity of software that leaves the organization's control, such as shrink-wrapped applications or thick clients

1. Create or interface with incident response: The SSG is prepared to respond to in incident. The group either creates its own incident response capability or interfaces with the organization's existing incident response team.
2. Identify software defects found in operations monitoring and feed them back to development: Defects identified through operations monitoring are fed back to development and used to change developer behavior.

1. Have emergency code base response: The organization can make quick code changes when an application is under attack. A rapid-response team works conjunction with the application owners and the SSG to study the code d the attack find a resolution, and push a patch into production.
2. Track software bugs found during ops through the fix process: Defects found during operations are fed back to development and tracked through the fix Process.
3. Develop operations inventory of applications: The organization has a map of its software deployments.

1. Fix all occurrences of software bugs from ops: In the code base. The organization fixes all instances of software bugs found during operations and not just the small number of instances that have triggered bug reports.
2. Enhance dev processes (SSDL) to prevent cause of software bugs found in ops: Experience from operations leads to changes in the development process (SSDL). The SSDL is strengthened to prevent a repeat of bugs found during operations.

• In 2009, the Financial Services Sector Coordinating Council (FSSCC) for Critical Infrastructure Protection and Homeland Security and the Financial and Banking Information Infrastructure Committee (FBIIC) Cyber Security Committee formed a working group called the Supply Chain Working Group. It was composed of leading security and risk-management practitioners who agreed to work together to create a deliverable that is useful to IT managers and information security officers interested in improving the resiliency of their organization's supply chains. The outcome of this work, entitled “Cyber Security Committee Supply Chain Working Group Toolkit”.

• The Toolkit is divided into four channels:
  • Internally developed software
  • Software developed by a third party
  • Software purchased of the shelf
  • Hardware, firmware, appliances

• In each channel, the deliverables are divided into two sections:
  • A summary of survey results from four surveys (one per channel)of members of the Financial Services Information Sharing and Analysis Center (FS-ISAC) and members of the BITS/Financial Services Roundtable.
  • From the survey results, identification of leading practices to improve supply chain resilience was based on input from recognized subject-matter experts, including reference information for the growing body of information available on supply chain resilience.

• Merkow, Mark S., and Lakshmikanth Raghavan. Secure and Resilient Software Development. Auerbach Publications, 2010.