Embracing a Resourceful Information Security Culture

Following the news, it’s difficult to escape a sense that the defense community is mired in a Sisyphean game of information security (INFOSEC) catch-up.  It seems that as soon as a policy is embraced by government agencies and their industry partners, new threats emerge and existing dangers increase in magnitude.  

Reminders are ubiquitous: June 3 saw the opening of Bradley Manning’s court martial.  Manning, an Army private first class, is accused having illegally downloaded and forwarded huge amounts of classified information to Wikileaks.  A week or so earlier, the Washington Post published a report indicating that Chinese hackers had successfully penetrated at least a dozen high profile American weapon systems, including those tasked with critical air defense, battlefield mobility and maritime dominance responsibilities.  The list could go on.

Fortunately, many of the community’s INFOSEC challenges are philosophical and fiscal rather than technical.  As such, they can be addressed by harnessing currently available resources, which, in an era that pits escalating requirements against sequestered budgets, is fortunate indeed.  The remainder of this article discusses four key improvement vectors that will enable the defense community – government and industry - to begin to address looming cyber and INFOSEC concerns, specifically: 

• Acquisitions staffing reform;
• Baked in INFOSEC;
• Automated auditing and monitoring; and
• The use of open source software.

Acquisitions Staffing Reform

Impeccably trained by organizations such as the Defense Acquisition University (DAU), the US Department of Defense (DoD) fields what is arguably the finest team of program managers and acquisition professionals in the world.  These people, who are ultimately coordinated by the Under Secretary of Defense for Acquisition, Technology and Logistics (AT&L) are extremely well versed the art of buying goods and services.  Assisting and advising the program managers are military and civilian experts who are charged with ensuring that the goods and services received are of best value and most use to the end users.

Unfortunately, these advisers, while well versed in operational needs and utility are generally not technical experts with regard to software and computing technology, especially as it applies to cybersecurity or its constituent disciplines such as infrastructure security, application security (AppSec) or malware detection and remediation.  As a result, program offices are placed in the position of relying on the same engineers and developers who are paid to develop systems for technical advice.  The contractors, in turn, may have a conflict of interest between the roles of advisor and solutions provider.

Solving this problem requires a fundamental augmentation to the acquisition community’s capabilities in terms of technical expertise.  Near term resources are available from existing DoD-affiliated expert organizations such as university affiliated research centers (UARC) and federally funded research and development centers (FFRDC).  It is likely that acquisition community will need expand this resource pool (either through direct government hires or through the use of contracted technical validation expertise) to fully represent the technical INFOSEC skill set.  

The silver lining to acquisitions staffing reform is the promise of overall lower system acquisitions costs as INFOSEC gaps are identified and remedied at the requirements level instead of after coding, an important benefit in the era of sequestration.

"Baked in" INFOSEC

The current model for incorporating and validating INFOSEC requirements and capabilities focuses on the tail end of the software development life cycle (SDLC).  While there are some proactive measures, such as the use of approved software tooling or adherence to Security Technical Implementation Guides (STIG) issued by the Defense Information Systems Agency (DISA), most INFOSEC activity takes place after a system has been developed.  

Typically, when a developer completes a new system (or a modification to an existing one), it is submitted for certification and accreditation (C&A) review.  The review includes security validation testing against the required information assurance controls (IAC).  At the conclusion of testing a list of vulnerabilities and mitigations is created, which are then negotiated into actions by the government program manager, the developer and the reviewing organization. 

The fixes are then applied to a completed, coded system, often requiring significant rework, time and expense.  More troublingly, many of the fixes take the form of a security applique, layered on top of the existing system.  These security appliques often compromise the system’s mission utility by increasing operator workload.  Systems featuring this applique approach are also inherently less secure than those that have incorporated INFOSEC mechanisms into their architectures from the beginning. The National Institute of Standards and Technology (NIST) recognized the benefits of designed-in INFOSEC in Special Publication 800-27 Rev A,Engineering Principles for Infomation Technology Security (A Baseline for Achieving Security), which specifies that security should be an integral part of overall system design.

Applying – and validating – INFOSEC capabilities early in the SDLC, at the requirements an architectural levels, not only creates more secure systems, it also cuts down on the expense of rework often necessary to meet C&A guidelines, resulting in more fiscally responsible systems acquisition.  The achievement of “baked in” INFOSEC rests on what we’ll call a “strategic security triad.”  The triad consists of:

• Requirements stemming from authoritative laws, regulations, policies and guidance (LRPG);
• A DoD-wide library of modular, standards-based, approved INFOSEC implementation patterns; and
• DevOps principles of continuous integration and automated testing.

Fortunately for the community, all three legs of the triad are represented by resources that are currently and economically available:  

The DoD is replete with mature, forward leaning INFOSEC LRPG. Typical of these is the Defense Information Enterprise Architecture (IEA) published by the DoD CIO’s office.  The document mandates basic principles of secured access such as assured identity, threat assessment, policy-based access control and centralized identity, credential and access management (ICAM).

An implementation pattern library would include pre-approved INFOSEC tools as well as requirements for what the tools have to accomplish for the system, and how they are to be implemented.  There are many INFOSEC tools currently available from industry.  These include things such as IBM’s Security Framework product line and CA Technologies’ Identity Minder.   

Interesting from a government perspective is the emergence of supported open source products into the INFOSEC space.  These tools offer the promise of open standards, modular design and implementation and enterprise class performance – all with zero acquisition cost.  Typical of this line is the WSO2 Security and Identity Gateway Solution.  This solution integrates four WSO2 products, the WSO2 Enterprise Service Bus, the WSO2 Governance Registry, the WSO2 Identity Server and the WSO2 Business Activity Monitor (BAM) to provide a complete AppSec solution including authentication, authorization, auditing, monitoring, content-based filtering, input validation, throttling, caching and Single Sign-On.  

The last leg of the triad, continuous integration and automated testing, requires tooling that can implement strong programmatic governance.  By requiring all of a program’s developers to use a common, Cloud based development platform that includes automated testing, integration and build tools, both functional and non-functional INFOSEC requirements (such as ports, protocols and services settings) can be validated before a module is accepted for integration into the application’s trunk.  Modules not meeting the requirements are rejected, with a report indicating what the developer needs to address.  As a result, C&A testing is an ongoing, integral part of development, and end-state C&A activities are dramatically curtailed.  An example of such a DevOps platform is the WSO2 App Factory.

Automated Auditing and Monitoring

Among NIST’s computer security principles is the need to implement audit mechanisms to detect unauthorized use.  Implied in this requirement is the need to notify the administration and response team as soon as a breach or other unauthorized activity is detected.  Given the size and scope of system activity and transaction logs, it is necessary to automate this process to achieve the necessary timeliness.  

Essentially, auditing and monitoring is a Big Data analytics problem.  Fortunately for the defense community, industry has been focusing on Big Data Analytics for a number of years.  There are a number of analytics platforms available for this task such as Google’s Dremel, Apache Drill and the WSO2 BAM.  Like the others, WSO2 BAM provides the capability to perform rapid analysis on large scale data sets.  To this, however, WSO2 BAM adds alerting and customizable dashboarding capabilities, which can be used to ensure near-real-time notification of suspect events.  When compared to currently acceptable auditing paradigms, some of which allow for a week or more between manual inspection of security logs, this represents a significant capability improvement.

Open Source Software

The most obvious benefit associated with open source software is cost.  Generally available without licensing fees, the use of open source software makes it much more cost effective to incorporate advanced INFOSEC capabilities than proprietary software.  However, while open source software contributes to lowering a system’s total cost of ownership (TCO) it is not without cost as development and production support services generally require paid subscriptions. 

Open source software has an added security benefit that is particularly compelling.  Specifically, open design and source code enable broad based, detailed code inspection and the rapid detection of both flaws and threats.  The idea that proprietary software is more secure because the source code is hidden just doesn’t stand up to scrutiny.  NIST’s selection of the Rijndael block cipher as the Advanced Encryption Standard (AES) in 2000 followed a nearly three year process in which a number of algorithms were publicly discussed, debated and cryptanalyzed.  In another case, Borland published and widely sold the InterBase database for seven years.  In 2000, InterBase was open-sourced as the Firebird project. Within five months of the product being open sourced, a hard coded backdoor (username “politically,” password “correct”) was discovered.

Conclusion

Strong system INFOSEC is in the best interest of the entire defense community.  While there have been both doctrinal and cultural fits and starts with respect to effective, community-wide policies, a fortunate confluence of technology, development philosophy and leadership exists that can allow the closure of critical security gaps.  As computer security expert John Pescatore noted at the June 4 Kaspersky Government Forum, we need to find the balance between perfect solutions that work, but are untenable and solutions that work and are tenable, but might not be perfect.   Acquisitions staffing reform, baked in INFOSEC, automated auditing and monitoring and the use of open source software are the first big steps toward tenable.