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.
