What Lies Beneath
In 2009, hackers attacked the Cumberland County Housing Authority using the Clampi virus and stole $480,000. I saw that event as an opportunity to get the security assessment the county had wanted for a number of years.
Although my IT team had nothing to do with the Housing Authority's network, our Board of Commissioners sat on its board, and they were concerned. The next day I was called into a meeting with the board, the director of finance, the controller and his staff, and the treasurer to discuss what happened, our information security practices, and what we could do to ensure we didn't fall prey to the same type of attack. Three months later, we began our first information security assessment; we're now in the remediation phase.
Many organizations simply assume that their security technologies protect them from threats. But without a test, how do they really know? Although calculating return on investment isn't possible with most security solutions, testing security in a real-world scenario can prove that it is deployed and functioning correctly. Taking that step requires the support of leadership, staff and a good vendor partner. What follows are some lessons we learned about conducting a security audit.
Get Buy-In
To complete the security assessment, we first had to convince county leadership that the investment in a security assessment was prudent. To do this, we capitalized on the uncertainty surrounding the Housing Authority breach when we raised the need for a security assessment.
When convincing leadership, it's important to walk a fine line between the repercussions of a lack of security and being overconfident to the point of not needing the assessment. We explained that our security protections were not necessarily more advanced than our attackers, just more secure than the other departments that were being attacked first. We made clear that we needed to conduct an assessment to stay ahead.
Determine Needs
To create our specifications for the exercise, we first had to decide what we needed and what industry rules, laws or standards were applicable to the different parts of our organization. After reviewing the different sets of rules from HIPAA, PCI and the ISO, we had a starting point for creating our requirements. This is where some of our own uncertainty got in our way. The fear was that "we didn't know what we didn't know," and therefore we did not want to pin the vendor down too tightly and have something important excluded from the assessment.
Pick a Partner
We began our vendor selection process with a series of interviews with potential third-party partners to better understand their process and how it met our goals. After interviewing six candidates, we narrowed the choices down to three. We asked the finalists to make a half-hour presentation to our leadership and make themselves available for questions.
We evaluated the companies based on process, individual certification, and relative team experience, along with the quality of presentations, responses to questions and cost.
With each vendor bringing different skill sets to the table, we decided to lay the framework for future information security assessments by considering hiring one organization, going through the process, remediation and then hiring a second vendor for an additional review from a slightly different perspective.
The next step was to proceed with the assessment.
Reassure Personnel
Just before the assessment began, I encountered an unanticipated roadblock. IT staff were concerned about the potenÂtial "gotcha" nature of the findings. Fearful that the findings could be used to punish them, these staff members weren't keen about helping the vendor. This situation was not going to get us the best information to help us better secure our network. My boss and I talked with the IT staff to address their concerns and also decided to reiterate this item with the leadership team at our next meeting.
Begin the Testing
The actual assessment took a few months longer than originally planned, but it was an interesting and valuable experience. We needed to plan around payroll processing, elections and a property reassessment.
The security assessment started with a penetration test of Internet-facing servers, which was to proceed only to the point of identifying vulnerabilities. If such a situation arose, our plan was to create a copy of those servers in a test environment for additional testing and remediation (and retesting, if needed). This plan should have been better defined in the contract, as the retesting was not planned for and was lost in the process. Then the assessment advanced to an internal vulnerability scan. This provided an opportunity for us to learn more about some tools that we could use for our own tests.
The third phase of the assessment was to test our end users. To do this, we tested 40 employees' responses to a phishing e-mail sent by the vendor and two departments' responses to a social-engineering attack in which the vendor tried to remove a computer from the office. Finally, the vendor performed a policy review that compared the elements that they felt we needed with what we had in our various policies.
Process the Findings
The findings were provided to the IT staff and then later presented to the leadership team. We were prepared for most of what was reported because of what we had witnessed throughout the process. There was a potential vulnerability identified in one of our websites, weaknesses pointed out in our patch management system, and items that needed to be cleaned up in our policies.
Our employees proved to be the biggest security challenge. Unfortunately, 50 percent handed over their user names and passwords as a result of the phishing scam, and one of the two departments let the attacker walk away with a computer. The vendor addressed the contradictory nature of years of customer service training with the reality of information security needs, which I believe put this issue in context for county leadership.
Fix the Problems
We are currently in the remediation phase, where we have identified other systems that -- while they passed the test -- are going to be a limitation in the future. We also received backing from the county commissioners to require end users to successfully complete a test as part of our mandated annual security training.
We now know which systems were not functioning at the level we thought they were. In developing the requirements for future assessments, we need to be more confident and define a minimum set of requirements. We also know that we are more knowledgeable than we thought we were, and that peace of mind is worth a lot. Now, we need to make sure no one is complacent.
