Fit for purposeIn any context, information assurance involves trade-offs and compromise along several dimensions in order to achieve or exceed performance requirement thresholds for confidentiality, integrity, and availability. In the domain of software development, these requirements include the systems and software that provide user- and customer-facing capabilities, and also encompass the environments, systems, and data/information used to support the build-out of these capabilities. In addition to the standard activities that support secure network operations, decisions need to be made regarding trade-offs between flexibility, convenience and security controls to provide an appropriate level of assurance for a given project or implementation. We typically consider three levels (Low, Medium, and High) when categorizing the security posture of a given software system. A typical low assurance system would be a public facing website implementation that provides information to unauthenticated users. There may be some administrative functions that require privileged, authenticated access for a few users, and the primary consideration is configuration control, rapid implementation, branding support, information dissemination, etc. Beyond the non-disclosure considerations typical of any customer engagement, the primary information protection concerns revolve around unintended defacement and the like. Medium assurance systems generally involve business relevant tools that handle information exchange between authenticated principals (people or computers), normally require some reasonable level of identity verification in order gain access to the information managed by the system, and may support various levels of high-availability and transaction integrity at production run-time depending on the specific capabilities, end-user profile, and user-base of the system. High assurance systems generally involve computing assets that store, manipulate, or transmit business critical information, handle personally identifiable data, manage financial transactions or other sensitive and targetable/exploitable data contexts.
ConcernsIn addition to the controls required to achieve specific performance thresholds along the dimensions of the three primary IA goals generally considered by the InfoSec industry (Confidentiality, Integrity, Availability), the creation of software and the systems that run it bring some different challenges and requirements into focus. Not only should consideration be given to the data and information handled or hosted by the system in question, but the various code artifacts and information about these artifacts and the environments used to produce them must be included in any risk assessment. This can lead to a bit of a ‘rabbit-hole’, but in general, the additional ‘security relevant’ events can be categorized as:
- Exfiltration of source code or other artifacts. This may provide malicious actors insight into specific vulnerabilities or behaviors that could be exploited during an attack. This is addressed by meeting the Confidentiality goals of the development environment, but may also impact the Integrity goals of any resulting system.
- Unintended exposure of sensitive information during development, demonstration, or in support infrastructure or project tooling. This is directly related to the Confidentiality goals of the controls in place to protect the data an information system will transmit or store, in addition to those of the system itself.
- Injection of unintended behavior, through source code manipulation, or introducing vulnerable configuration artifacts. This class of risk can be attributed to malicious intelligent actors, design flaws, or code bugs and implementation problems.
ApproachBy approaching Information Assurance goals defined by the requirements of the system, the role and purposes the system is designed to fulfill, and the performance thresholds of the customer in a holistic manner, and treating these goals in the context of software development and system build-out as deliberate design considerations of the overall solution, we are able to incorporate sufficient and appropriate controls as needed at the least cost possible. We are also able to inculcate a culture of security into the development team(s) that build the software and computing systems to meet the business requirements of the customer, and provide competitive advantage to their organizations.
Solution Elements and IA GoalsWe leverage a variety of specific technical, procedural, and social elements to achieve the Information Assurance and Information Security goals along the primary dimensions of Confidentiality, Integrity, and Availability required by a project and its associated security posture. These elements are outlined in the following sections. It should be noted that while a given element may impact multiple IA goals, they have been listed where I believe they provide the highest value.
- Authenticated and access controlled source code repositories and development environments ensures that only those individuals who need access to the source code and related artifacts for a given software system have it. This also provides an auditable series of event logs in the event of unauthorized access.
- For some projects, developers must execute various non-disclosure agreements, possess clearance or some organization-internal trust certification, and/or a specific set of attributes (e.g. citizenship) in order to qualify for participation.
- Hardened systems configured in accordance with InfoSec industry best-practices, DISA Security Technical Implementation Guides, and NIST SP 800-53 as appropriate for the IA goal thresholds for the project systems ensure that throughout the development cycle from architecture, through design, implementation, testing, demonstration, qualification/certification, and productionalization activities, the computing tools and assets that support these activities enforce the IA posture suited to the project.
- Pair programming elevates not only the quality of the code-base, but also the integrity of the artifacts that comprise the code-base by implementing a form of dual control over code elements and implementation details associated with a given system.
- Periodic code review, generally implemented just prior to or during merge activity cycles provides a ‘third party audit’ of sorts and is intended to add an additional quality and integrity control to the overall code-base.
- Test frameworks provide unambiguous evaluation mechanisms and automation support to validate many attributes of software systems including designed behaviors, capacity requirements, and the presence of various technical enforcement mechanisms for policies, including those related to InfoSec.
- Auditable commit logging ensures that changes to the code-base can be attributed to specific individuals, and the evolution of the software can be retraced for any of a variety of reasons.
- Configuration management and control ensures that any information required to successfully participate in any portion of the development process is appropriately captured and cataloged.
- Dedicated build automation ensures that builds are executed consistently, and the systems that convert source code artifacts into run-time executable software are appropriately isolated from e-mail clients and internet-exposed web browsers.
- Cryptographic hashing provides a mathematically verifiable chain of custody (up to and including code signing where appropriate) for any software elements from build to production.
- Our Agile software development practice enhances system availability by providing value to the customer and end-user as early in the system implementation process as possible by encouraging priority focused, iterative capability delivery with an emphasis on the run-time manifestation of the project’s product.
- Open standards and modular system architectures enhance integration and interoperability, and provide some level of ‘future-proofing’ a given software system and are intended to provide the greatest longevity over the lifespan of a given application.
- Building upon proven stable platforms minimizes the risk of future vulnerabilities in a given application suite, and reduces the amount of effort required to implement a robust capability by reusing platform elements that have a demonstrated level of reliability and stability.
- Building software systems to scale to a level driven by the projected capacity requirements of a given application protects against unnecessary or ‘premature’ optimization that can lead to implementation delays and valueless costs.