Before Jonathan Trull took over as Chief Information Security Office for the state of Colorado in 2012, he had already been working in the Colorado Office of the State Auditor for a decade. As the Deputy State Auditor, he was responsible for overseeing annual audits of the state's systems.
It was during that time that Trull said he became concerned with what he observed as repeated mistakes and violations that were not addressed, and even took part in a penetration test on state systems with results he says were "horrifying."
Trull recently spoke with CSO about his new role, and how he hopes to create effective change in Colorado's security infrastructure--even on a miniscule budget.
CSO: You have an interesting story about how you came to the position of CISO of the state of Colorado. Tell us about it.
Jonathan Trull, State of Colorado: One of the catalysts was that I was doing the audit work in my previous position, and I came to a point where I was concerned about the seriousness with which people took the audit findings. A typical audit finding might be "your password complexity is not sufficient." It's pretty boring actually.
But, after a while, you see enough of those and there didn't seem to be a lot of progress in areas that I thought were critical--significant to the prevention breaches. We seemed to do well on compliance issues: check-box sort of stuff like "I've got this policy or procedure in place." But the question was: Has it been operationalized? Is it actually working?
[Also read Case study: Security on a shoestring budget]
To test that in 2010, my team and I did a covert penetration test against the state systems. The only person that knew was one person in the governor's office. We also wanted to test our security staff's ability to detect and respond to attacks.
The results were fairly horrifying. Really pretty bad. Significant breaches were accomplished by our team. We were able to steal thousands of confidential records of taxpayers, citizens. Shortly after that, the CISO in place left for another job and they asked me to come in and fix what I found.
Where did you start?
The SANS 20 critical security control seemed, to me, from my experience with doing pen tests myself, to be the best place to start. When I starting going through the list I thought "These will prevent the majority of how we got into our systems." Then it became a matter of prioritization.
It felt like a no brainer for me to focus on those areas first.
But I've got a very limited budget. I've got about ten staff across 17 departments, executive branch agencies and our operational budget for this year was $6,000.
In the state we divide our dollars between personnel (salaries) and operating (software, tools, professional services, et cetera). Our fiscal year runs July 1 to June 30. The total operating budget available for the year was probably around $35K. Our fiscal year runs July 1 through June 30, and $6,000 was what we had left for the year when I started in September.
The question became: how can I make the most impact quickly?
I'm shocked at your budget figures. Are you anticipating more in the future?
We are in the middle of fighting for a budget of between $1.1 and $1.7 million a year. We feel strongly that with that we will be able to implement the first five critical controls. The majority of the other 20 we plan to then implement within a three-year period of time, but we definitely want to keep our operational budget below $2 million a year.
How are you working with such a meager budget now?
For now, our strategy is to do the best with what we've got. We are using existing technologies. For example, application whitelisting. We have Microsoft products in place. It's not a perfect scenario, but there are some other representatives in the NSA (National Security Agency) doing it and we are trying to put it in place with the tools we have.
We are doing a lot with open source and other tools, and features that are already built into our existing software. A lot of this stuff isn't perfect and not as robust as some of the tools that are available, but, for example, Active Directory should keep a good list of the systems that are in your environment. There are other free tools like Nmap that allow you to do fairly robust scans to detect new and rogue systems on your network.
Even in the face of budget restrictions, have you made any significant changes yet worth highlighting?
I'm really pushing my staff to use a risk-based approach even in this deployment. Not all of our agencies are created equally. Some have much more sensitive data than others and we would be silly not to focus on those. It's the same as a persistent attacker who is going to do their homework and know what they are going after. We need to have the same mindset.
One thing that I did when I took over was put a stop on all security products. We were getting different requests for things like Splunk and ArcSight - requests all over the map. I didn't even know what I had yet. So I put a stop on all buying.
Once I did an inventory of all of the security products we owned, and all of the licensing and contract terms, I found we had a lot of shelf ware; things purchased years before that were now not being utilized. Excess licenses were everywhere.
Honestly, part of this is going to be a return on investment for eliminating products no longer being used or focusing on new ones we are going to actually put to use.
What specific goals are you bringing before lawmakers to make the case for getting that budget figure you mentioned earlier?
We're tying all of this to a three-year initiative that I am calling "Secure Colorado." The focus is on the SANS critical security controls in terms of our operational security posture. As I said before, we're focusing on the first five within 12 months, and, over the next three years, we will deploy the rest of the 20.
Other goals include using our existing vendors as partners to help us get this done. One of the things we saw in the past is a lot of activity during the time of renewal--and then everyone disappears until it's time for renewal again. We just can't tolerate that anymore. We are really trying to build in to our contracts that you are partnering in our success and we are going to make it contingent on that. In other words, you only get a portion of this and the rest is hinging on successful deployment of this product.
We are also working on building the next generation of security workforce. We just started a cybersecurity internship program. Our first two cybersecurity interns started in January. College students. We are working with the different universities on that.
Those are the big areas. The successful implementation of the controls, the public and private relationships and building the workforce.
The data itself is proving quite useful in making our case, too. The number we get, in terms of our network, is it's getting hit 600,00 times per day by some kind malicious event. Whether its scanning viruses or malware, we can show the escalation in that as well. When you couple that with the stagnation of the funding and resources to the security program, I'm hoping funding will prove to be a no-brainer.
If so, what will be solid progress in a year? What will be some of the benchmarks you point to as proof of success when you need to go back and make the case for funding again?
We have a few benchmarks we set up that we will track closely. I wanted to put those in place before we even started because I knew we would be accountable.
We put together a scorecard, a security-metrics scorecard. It includes tracking the percentage of our systems that are under management. The way we define that is basically from a central location, the number of systems that I can view and observe their current risk and security status within a 48-hour period.
[Also read Information security, value creation and the balanced scorecard]
Other metrics include the percentage of critical or high vulnerabilities per every host. We are also looking at the number of successful malware infections and the number of computers that we have to reimage because of that. That number should really go down.
Those are our outcomes-based measures. We have other input-based measure we are looking at, too. They include number of hours per staff activity. The idea is the more we get things under control, the less time our staff should be spending on reactive-type issues. We should have a much less running around, putting out fires in the day.
The other thing is mean time to resolve an incident. We are looking for that to go down significantly as well.