What Should the Feds Do
Recently I discussed Federal digital security in Initial Thoughts on Digital Security Hearing. Some might think it's easy for me to critique the Feds but difficult to propose solutions. I thought I would try offering a few ideas, should I be called to testify on proposed remedies.
For a long-term approach, I recommend the steps offered in Security Operations Fundamentals. Those are operational steps to be implemented on a site-by-site basis, and completing all of them across the Federal government would probably take a decade.
In the short term (over the next 12 months) I recommend the following. These ideas are based on the plan the Air Force implemented over fifteen years ago, partially documented in Network Security Monitoring History along with more recent initiatives.
None of these steps are easy. However, there appears to be support for some of them. This is essentially the formula the Air Force adopted in 1992, with some of the steps (like friendly force projection) being adopted only recently. I appreciate any comments on these ideas. Please keep in mind these are 30 minutes worth of thoughts written while waiting for a plane.
Also -- if you read this blog at taosecurity.blogspot.com, you'll see a new theme. Blogger "upgraded" me last night, removing my old theme and customizations. I think most people use RSS anyway, so the change has no impact. I like the availability of archives on the right side now.
Update: I added step 6 above.
For a long-term approach, I recommend the steps offered in Security Operations Fundamentals. Those are operational steps to be implemented on a site-by-site basis, and completing all of them across the Federal government would probably take a decade.
In the short term (over the next 12 months) I recommend the following. These ideas are based on the plan the Air Force implemented over fifteen years ago, partially documented in Network Security Monitoring History along with more recent initiatives.
- Identify all Federal networks and points of connectivity to the Internet. This step should already be underway, along with the next one, as part of OMB IPv6 initiative. The Feds must recognize the scope and nature of the network they want to protect. This process must not be static. It must be dynamic and ongoing. Something like Lumeta should always be measuring the nature of the Federal network.
- Identify all Federal computing resources. If you weren't laughing with step 1, you're probably laughing now. However, how can anyone pretend to protect Federal information if the systems that process that data are unknown? This step should also be underway as part of the IPv6 work. Like network discovery, device discovery must be dynamic and automated. At the very least passive discovery systems should be continuously taking inventory of Federal systems. To the extend active discovery can be permitted, those means should also be implemented. Please realize steps 1 and 2 are not the same as FISMA, which is static and only repeated every three years for known systems.
- Project friendly forces. You can tell these steps are becoming progressively difficult and intrusive into agency operations. With this step, I recommend third party government agents, perhaps operated by OMB for unclassified networks and a combination of DoD and ODNI for classified networks, "patrol" friendly networks. Perhaps they operate independent systems on various Federal networks, conducting random reconnaissance and audit activities to discover malicious parties. The idea is to get someone else besides intruders and their victims into the fight at these sites, so an independent, neutral third party can begin to assess the state of enterprise security. The Air Force calls this friendly force projection, which is a common term but they are performing it now on AF networks.
This step is important because it will unearth intrusions that agencies can't find or don't want to reveal. It is imperative that end users, administrators, and managers become separated from the decision on reporting incidents. Right now incident reporting resembles status reports in the Soviet Union. "Everything is fine, production is exceeding quotas, nothing to see here." The illusion is only shattered by whistleblowers, lawsuits, or reporters. Independent, ground-truth reporting will come from this step and from centralized monitoring (below). - Build a Federal Incident Response Team. FIRT is a lousy name for this group, but there should be a pool of supreme technical skill available to all Federal enterprises. Each agency should also have an IRT, but they should be able to call upon FIRT for advice, information sharing, and surge support.
- Implement centralized monitoring at all agencies. All agencies should have a single centralized monitoring unit. Agents from step three should work with these network security monitoring services to improve situational awareness. Smaller agencies should pool resources as necessary. All network connectivity points identified in step 1 should be monitored.
- Create the National Digital Security Board. As I wrote previously:
The NDSB should investigate intrusions disclosed by companies as a result of existing legislation. Like the NTSB, the NDSB would probably need legislation to authorize these investigations.
The NDSB should also investigate intrusions found by friendly force projection and centralized monitoring.
None of these steps are easy. However, there appears to be support for some of them. This is essentially the formula the Air Force adopted in 1992, with some of the steps (like friendly force projection) being adopted only recently. I appreciate any comments on these ideas. Please keep in mind these are 30 minutes worth of thoughts written while waiting for a plane.
Also -- if you read this blog at taosecurity.blogspot.com, you'll see a new theme. Blogger "upgraded" me last night, removing my old theme and customizations. I think most people use RSS anyway, so the change has no impact. I like the availability of archives on the right side now.
Update: I added step 6 above.
Comments
Is it unavoidable that regulations related to security/compliance go down this path?
WRT #2, for all the NSM data we collected, and events we traced back, our biggest headache was finding the box and an owner to mitigate the situation. At almost every mid to large company I've been with, there is always a problem with inventory.
Anyway, just keeping those routes shut down was like playing whack-a-mole. Thanks for the fun article.
Do not use personal identifiers (such as a Social Security Number) as a login ID.
Some of the .MIL networks do this. If your wondering how I know, it's from the backdoor logs of a trojan. Multiple users, multiple logins, multiple access locations.
First, what I agree with:
Idea three, 'Projecting Friendly Forces' is a good idea. Random penetration testing and pop reviews are needed. IG's already can do this a bit under the FISMA process but a regular independent organization is a better solution. There are downsides of course, to survey the network in its natural state you need to do it unannounced. So ISSO's will be having heart attacks until informed later of the test. That means the testing is an effective blind to real network attacks. While 'Projecting Friendly Forces' has that sense of bravado and militarism so popular these days I can think of another term for it: policing.
Idea five, centralized monitoring on a per agency basis is also a good idea, but a bit amorphous as cast. What is meant by an agency? What do you mean by monitoring? Who reacts to problems? Who gets informed of problems when they are detected? What is being monitored? Are we talking strictly network security? Is network monitoring particularly important given where data breaches typically occur? What if whole agency monitoring makes for a less effective system than distributed monitoring? How do the monitors stay abreast of all network access points given the ease by which they can be established?
Idea 4 is CERT. I imagine it is an idealized and improbable CERT, but still CERT.
Now for where I disagree:
In general these recommendations seem aimed squarely at external threats, 'bad guys' out on the internet. These 'bad guys' weren't behind most of the massive data breaches recently. The 'good guys' on the other side of the firewall, who lost laptops and storage devices were responsible. Not to say that external threats should be ignored, only considered in proportion to other threats. It is to say that network security is not the whole of security.
Idea 6 is possible but potentially dangerous. Do you really want or need another Federal agency to investigate things and making jurisdictions murkier? Hard to imagine it becoming anything but a cyber-FBI.
Ideas 1 and 2 are being done via standard security practice in support of FISMA. See my nitpick below regarding your statement that FISMA is some static and periodic activity.
And some individual nitpicking:
Your Security Operations Fundamentals map closely to components of FISMA. I wrote it out but it's probably more detail than you are interested in. There are differences, mainly because the former is focused on network security while the latter approaches security in a holistic manner where network security is a component.
Idea 2's last sentence states FISMA is static and happens every three years. That's inaccurate in fact and in characterization. It's like saying that public companies reporting to the SEC once a year (okay, quarterly plus) means they don't do accounting or auditing the rest of the time. By law every year each agency must perform an independent evaluation of the InfoSec program (FISMA §3545(a)(1)), report those findings (FISMA §3545(e)(1)) and have those findings reported to Congress (FISMA §3543(a)(8)). The SP-800-37's Certification and Accreditation process takes place every three years, but those are two phases followed by a Continuous Monitoring phase. It's more accurate to think of the periodic evaluations and C&A phases of FISMA as points where government InfoSec people are forced to think through security systematically as opposed to the day-to-day reactive way everyone deals with security.
Finally:
I think my major disagreement here is with the network security focus. I can't say it often enough, network security is not all of security. It's an important part but it should be given consideration proportionate to the demonstrated importance of other parts. Creating good security means looking at everything through a process of risk mitigation to determine the points where you can affect maximum security benefit at the least cost, in function and resources, for the system.