In November 2008 I attended an “Information Assurance Conference” in Arlington, Virginia. This was a non-refereed two-day workshop of 30-minute talks on policy-level IA issues in the DoD and homeland security environments. The most interesting takeaways were:
- If you are an organization that wants information assurance, give someone the high-level independent power to veto (or vet) which applications are allowed to use the network.
The U.S. Marine Corps has an outstanding example of this power used successfully: “the HQMC IA division will be the single point of contact within the marine corps for IA program, policy matters and oversight…[Mr. Ray Letteer] has authority to approve or disapprove an application or system for connection to [all Marine Corps core networks].” And, according to Ray (the speaker), the USMC really has given him the teeth to enforce his team’s IA policies.
Such a position of course requires diplomacy and tact: Ray mentions that he carefully vets the classifications of potential vulnerabilities to make sure only applications with demonstrable and unmitigatable vulnerabilities are ultimately banned from the network; he describes his role as translating geek-speak to the senior officers to convey the need for the restrictions his team enforces.
After a cursory look I feel that this USMC approach could serve as an best-practices reference model for many other large organizations. Another speaker noted that the traditional corporate and DoD approach is to have local administration (each division-sized entity has its own IA unit as part of its IT function), whereas the military is moving toward a single unifying enforcement point staffed by well-trained operators. (I asked “isn’t homogeneity terrifying?”; other speakers responded that homogeneity doesn’t have to mean single-point-of-failure — they are not talking about one point of deployment, they are talking about unified policy across all points of deployment.)
- If you need an ROI (return on investment) story to sell an IA strategy to your management, you’re in luck.
Three speakers emphasized the availability of ROI metrics. Joe Jarzombek described the free software assurance tools that are available from the Department of Homeland Security. As part of that effort DHS published seven articles on making a business case for software assurance (sample title “A Common Sense Way to Make the Business Case for Software Assurance”; click on the “Business Case” link at the above site) and recently held a workshop on the topic.
Two other speakers suggested taking a nonstandard approach in selling security investments to your upper management: instead of justifying your existence, focus on demonstrating your continued competence. For example, present graphical weekly metrics of how many port scans you thwarted or how many new security vulnerabilities were announced by antivirus companies that you prevented from affecting your network.
Or, pick some of the low-hanging fruit to impress the bosses: Dr. Eric Cole of Lockheed-Martin mentioned a client engagement where his team was asked to suggest architectural changes to a network that was operating at 99% utilization. After looking at the network traffic, his team simply blocked 74% of the outgoing connections (i.e., those connections which could not be traced to a business purpose). Nobody complained, and the utilization was reduced to 55% at no cost to the customer.
- If you are not a member of senior management, you need to learn to speak the language of senior management.
This theme came up over and over during the workshop. “Speak the language of executives — translate your geek-speak into business objectives!” All I can say is: I agree.
Four other quick notes from the workshop:
Whitelisting: One speaker mentioned a trend toward whitelisting web sites as a means of IA in military computer networks. (Whitelisting is enumerating the list of acceptable sites and denying access to any other sites.) I hadn’t heard that before — can anyone confirm you’re seeing this?
COTS: Is COTS still on the rise? Some speakers and attendees noted a trend toward COTS software and hardware, chiefly for the purchase costs and especially the (comparatively low) maintenance costs. Others noted that there remain many applications, especially in classified domains, where commercial vendors are unwilling to tweak their product to fit the needs of the space, and/or there is too much inertia or turf-war to switch away from specialized development systems.
Metadata: I was delighted to see a talk about metadata by Carol Farrant, whose team is interested in collecting, analyzing, and using metadata in data management for the intelligence and military communities. Of the technologies I heard discussed during the workshop, this is the one whose core technologies are arguably the least developed in the research and commercial environments. Unfortunately her team is underfunded and understaffed, so she is actively seeking volunteers to help move things along. (She notes that in the past year she’s seen more volunteer interest on the topic than on anything else in her career.) This might be an opportunity for an academic to have a big influence on metadata use and tool development.
FPGAs: I’ve been a fan of programmable logic since working with FPGAs in Dr. Richard Chapman’s research lab at Auburn. The final speaker of the workshop, Jonathan Ellis, claimed that the moment is at hand for reconfigurable logic to be used the way it was always intended — specifically, actually reprogramming the chips (frequently) during normal operations. Vendors are currently working to make this possible (if I heard correctly: although the chips can support multiple independent execution units on them, they currently have to be completely wiped to be reprogrammed. Not for long.) FPGAs have come a long way in 10 years: he asserts that software toolkits for ease of programming and implementation — arguably the biggest barrier to their widespread use — are right around the corner. He also noted that the current thinking is if you are building 100,000 or fewer units of something like cell phones, it’s more cost-effective and time-efficient to pump out FPGAs (instantly available and upgradable) than to send off for ASIC fabrication (expensive, two month lead time).
I thank the hosts of this event, Technology Training Corporation, for sending me a complementary pass to attend the workshop. (This workshop was similar to the “cyber security conference” I attended in June.) Overall I would likely not attend this workshop again, as I (as a practitioner of basic and advanced research) am not really in their target audience. People who I think would be interested are people involved in policy-level marketing and sales for large government contractors, Marc Krull, and government employees involved with large program development and management.