Prior to seeing this diagram I had heard a lot about "net-centric warfare" but I had no real grasp of the underlying. It seemed more of a buzzword. Now I understand the idea of getting information from any source to the people who need it, instead of, say Air Force sensors sending data to Air Force decision-makers who feed Air Force assets.
Given the net-centric model, DoD needs to move away from a "System High" model of security to a "Transactional" model. In the System High world, you essentially define a perimeter by classification (e.g., "Secret"), build a network for that classification (e.g., SIPRNET), and let anyone with a Secret clearance see anything on SIPRNET. This is procedure-based security at its best (actually, it's worst).
This figure shows how DoD wants to transition from the existing model to the new model. It's moving away from the current "baseline" in "increments," starting with Increment 1. Completion of Increment 1 is expected with the conclusion of the next five-year DoD plan, lasting 2008-2013 (!).
DoD's experience with coalition warfare in Iraq and Afghanistan is driving these changes. One example involved the need to establish a separate network for every coalition partner. In one so-called "coalition village," DoD had to build 14 separate networks (US-UK, US-Poland, US-Italy, etc.). This is obviously costly and time-consuming. In the new model, these coalition partners will share one network but have access regulated by the transactional security model. Virtualization and Digital Rights Management are going to be key for implementing these ideas.
This figure explains the layers present in the Enterprise Sensor Grid, and the idea that DoD is moving away from a strictly perimeter-based monitoring model to one that reaches all the way to end hosts.
One of the briefers offered a set of metrics that I found interesting.
- % of Red Team simulated attacks that are successful
- % of remote access to DoD information systems and DoD access to the Internet regulated by positive technical controls such as proxy services and screened subnets
- % of DoD systems and applications that conform to the DoD Ports, Protocols, and Service Policy
- % of standardized and approved IA and IA enabled COTS products available to protect DoD sensitive and classified data (vs. GOTS)
- % of NIPRNet Traffic that is encrypted
I found the first metric to be especially interesting because the DoD uses it to measure the number of attacks they are missing. In other words, DoD (wisely) understands that it doesn't detect all attacks. They use Red Team exercises to estimate the number of attacks they don't detect. This is exactly the sort of metric I believe to be useful. DoD also measures (and wants to vastly decrease) the amount of time needed to detect and respond to intrusions. Again, they base their metrics on Red Team exercises.
I left the conference with a few concerns. First, I heard an emphasis on "pushing systems to DMZs." The idea is to remove systems accessible to the public or coalition partners out of internal networks and into DMZs. While I agree that security zones are important, I wondering if DoD is fighting the last war again. Server-side attacks were the predominant model of the 1990s, bleeding somewhat into this decade. For the last three or four years, however, client-side attacks have been all the rage. DoD is moving to persistent and then pervasive monitoring (which includes end hosts), but I hope they don't ignore client-side vulnerabilities. On the other hand, the rise of Web Services might reinvigorate DMZ-focused security.
After hearing one briefer joke about not understanding so-called "honey" technologies (honeypots, etc.) I worried that some of these decision-makers don't understand the attacks facing DoD networks. They of course understand the threat, because those groups change but not as quickly as the tools and techniques they employ. Keeping up with the vulnerabilities and ways to exploit them is extremely challenging, and does not map at all to five-year plans.
A second problem involves the so-called "black core." This is an encrypted network which will eventually dominant the DoD enterprise security model. This is similar to Microsoft's reported internal use of IPSec everywhere.
The black core emphasizes confidentiality, and to a certain degree integrity. It seems to sacrifice visibility. An IATF attendee made this point in a question. If just about everything is encrypted, what's the point of network-based monitoring? One of the speakers replied that flow-based monitoring (i.e., analyzing session data) will still be helpful, but sessions only take you so far. I wonder if DoD might implement some "visibility taps" that decrypt-inspect-encrypt at various points in the black core?
Speaking of encryption, crypto appeared to be a major factor in DoD plans. This isn't surprising, given the IATF's sponsor. Still, most security incidents don't happen because of failed crypto. Intrusions are often the result of improper configuration and operation. I didn't hear much about addressing those problems, yet I heard that DoD is cutting IA personnel and funding!
Third, IPv6 wasn't formally mentioned in any of the presentations. An attendee had to ask about it specifically. An audience member from the Office of the Secretary of Defense said IPv6 would work with DoD's plans, but I think the audience was skeptical.
Finally, DoD is relying heavily on vendors to build the equipment and technology needed to implement its vision. Ideas of "protecting data in transit" (PDIT) and "protecting data at rest" (PDAR) are great concepts, but implementation questions remain. DoD also seemed not interested in data stored outside of its own systems. An attendee questioned how DoD is going to handle that concern, but it appears to have been largely ignored. This is a growing issue as we approach the end of this decade, and I predict it will be a major issue in the next decade.
Incidentally, while driving to the IATF meeting I listened to a story on NPR about Boeing's plans for border security. One of the engineers in the story talked about the false positive problems caused by tumbleweed! Maybe I should consider investigating cross-discipline intrusion detection problems (i.e., digital, financial, homeland security, and so on)?