With the end of the 30 day Cybersecurity Sprint that U.S. CIO Tony Scott announced on June 12th rapidly approaching, I thought it would be a good time to look both the 30 day goals as well as the goals of the Cybersecurity Sprint team that will report out at the end of the sprint.
ClickToTweet: What will result from the Cybersecurity Sprint? http://bit.ly/1Jlabp0
Four focus areas that must be reported on to the Department of Homeland Security (DHS) and to the Office of Management and Budget (OMB) by the date are:
- Fix all critical vulnerabilities within 30 days (from the issuance of the May 21 directive from the Department of Homeland Security)
- Tighten policies for privileged users
- Accelerate the adoption of multi-factor authentication – especially for privileged users but also for wider employee sets
- Immediately deployment of indicators supplied by DHS to scan systems/logs to detect attack or the possibility of a breach (possibly this is the Einstein 3A software discussed here)
I have to think that most of what we’ll see is “reporting” at the end of the sprint. Given the scope of these changes, we can’t realistically expect that organizations will meet all of these requirements in time for the deadline.
Fix all critical vulnerabilities. This is harder than it looks, unless machines are enrolled in with a configuration management system. OS patches can be easily enough done with standard patch and update software, but application and configuration vulnerabilities depend on application software, and on organizations understanding how to find, and deploy security level patches for the apps. If the definition of “critical vulnerabilities” is narrow enough, the window can be met. But software and processes have to be in place for applications as well. It isn’t enough to just roll out changes as they come in from the application vendor, as there are too many dependencies in production systems. A full change management process has to be followed to reduce the risk that untested patches to application level software will crash a critical application. There is a good chance that internet facing systems (as the most critical ones) can have the majority of critical vulnerabilities found and fixed, but full compliance for all internet facing systems, and then all systems connected behind them on the network will be longer than a 30 day process.
Privileged users – Privileged user “policies” for how they operate (on paper) for instance, can change, but enforcement requires selection, purchase and deployment of solutions to the problem. What’s more, implementing the hardware and software required for multi-factor authentication of privileged user accounts has the dual problem of getting enough hardware and enforcement on the software platforms. While the software side is more easily done for domain level roles, system level roles (such as that of root users on UNIX and Linux systems) will require a different approach. So while a start can be made, fully implementing these policies will be time consuming and expensive.
Multi factory authentication – While it is “somewhat” more feasible to at least get the hardware for privileged users, It also isn’t realistic to expect that the millions of federal employees without smart cards or other multi-factor authentication solutions can have something in place by the deadline. Just the hardware purchase and procurement problems prevent it. Something simple along the lines of what Google does with account access – requiring an authentication code sent by via a text might happen sooner, but definitely is not as secure.
View the original content and more from this author here: http://ift.tt/1LSiWa9
from cyber security caucus http://ift.tt/1R1mzRY
via IFTTT
No comments:
Post a Comment