Governance , Incident & Breach Response , Next-Generation Technologies & Secure Development

Security Program: Elements of Success

Auxilio's Mike Gentile on How to Benchmark and Address Gaps
Security Program: Elements of Success
Mike Gentile, Auxilio

If the past year of breaches has taught us anything, it's that there is absolutely no such thing as 100 percent security for any organization. What, then, does a truly successful program look like, and what are its key elements?

Mike Gentile, executive vice president of innovation and security at solutions vendor Auxilio, discusses the urgency for organizations in all sectors to stand up a formal security program.

Bottom line, Gentile says, this urgency is a sign of the times.

"A couple of years back, when we used to go talk to executive teams about information security and what they wanted to do ... they always had the option to do nothing and not really experience any downside," Gentile says. "[Today] the cost of doing nothing is really much more expensive than actually fixing the problem and building a repeatable system to address security."

Among the critical elements of a formal security program: Creating a benchmark for the program; measuring against that benchmark; identifying security gaps; and then using your data to present to senior leadership and get funding for remediation.

In this interview, Gentile discusses:

  • How to build and measure a formal security program;
  • The risk of doing nothing;
  • What a successful program truly looks like.

Gentile is on a mission to change the status quo in information security as we know it. His goal is to translate the discipline from one that is often misunderstood, inefficiently applied and painful to one that is a seamless, collaborative, and repeatable in healthcare organizations nationwide.

His core focus over the past 15 years has been developing enterprise security programs for countless leading public, private, and government organizations with expertise in healthcare. As a researcher, he has contributed numerous publications within the information technology, project management, and security communities. He is a co-author of The CISO Handbook and CISO Soft Skills.

Need for a Formal Security Program

TOM FIELD: As we know, organizations have been practicing information security for years, but what's the sudden urgency now to have a formal security program?

MIKE GENTILE: It's really easy. The urgency is associated with the dramatic rise in the costs associated with organizations that choose to do nothing. In the past, as organizations really explored what they wanted to do for security, it would go to management. They would look at it, and, many times, organizations would choose to just not do anything and go on as they were, and that model actually worked okay. They would do that and they weren't getting attacked all the time. Regulators weren't really auditing that tight, so they could do nothing, not spend the money and not feel the ramifications that many organizations are feeling today.

What's happening today is that organizations are getting attacked on a daily basis. If they choose to do nothing, they're continuing to get attacked - at the same time, data is getting taken from these organizations during these attacks - and the cost from a regulatory perspective has dramatically risen. They're paying larger and larger amounts in fines and remediation to clean up these items, which is really getting them to a point where if they continue to do nothing, they basically will go out of business.

Establishing a Benchmark

FIELD: You've outlined some pretty solid steps to building a security program. I'd like to ask you about them, starting with benchmarking. How does one create a security benchmark for their specific environment?

GENTILE: A security program is a component of four things. The first element is that you need to establish what it is that you want to measure in your environment - or, as you mentioned, the benchmark.

Once you have a benchmark in place for security, then that leads to the next thing that a security program really should do, which is the ability to measure against that benchmark. The process is to measure what it is actually, how your environment fares against what you've defined.

The third step in the process is that you can essentially take those gaps against your benchmark and be able to present them to management so that they can really do one thing - make informed decisions.

Then the fourth thing that a security program should be able to do is to support the implementation of those decisions in the environment. When it comes to establishing a benchmark, the good news is that many frameworks and such already exist. The key is that you choose one that covers all the appropriate areas and at the right depth of specificity - not too deep in terms of the areas and not too light. Good ones to start with are the ISO 27002 framework and NIST 800-53. Or, in order to get that right depth and specificity, a combination of both often works the best.

Measuring Security

FIELD: That takes us to our benchmark. Now we want to measure against that. What are some strategies for measurement?

GENTILE: The best way to measure is to really focus on three things. The first is that the measurement is applied across the whole organization. If that's a health system, that means that all hospitals should be measured, as well as a comprehensive set of departments in each hospital. If your health system is 20 hospitals, only measuring five isn't going to really give you an effective measurement. You're going to want to measure all 20.

The next is that the same area should be measured across the whole organization. You don't want to use the ISO framework in five of your hospitals, the NIST framework in 10 of your hospitals and then in the other five do something different.

Third is that the assessment should really be over the same timeframe. This is something that we see often. You look at an organization and - using the health system example - maybe five of the hospitals did a HIPAA risk analysis or an ISO assessment three years ago, another did one 10 years ago, and another just did one a year ago. You really want to do them all in the same timeframe, and the objective of that is that you're comparing apples to apples, and you get a consistent set of data.

Determining Which Gaps to Address

FIELD: Following your outline, we've got a benchmark, we're measured against it: How do we decide which gaps we're going to address?

GENTILE: Once you have a good set of data, the next step is to convert findings into remediation tasks, then aggregate tasks into projects, and then group projects into remediation programs of work. It's really converting findings to the world of project management. Along the way, you want to assign scope, schedule and budget to all of those initiatives at the program level and at the project level. Once done with this process, you'll know the story of your findings and how they associate to the cost of remediation work. Knowing the story and really understanding the story is crucial, knowing how to have a conversation to be able to tell management what they should focus on and why. The only way to do that is if you start from the beginning with where your gaps are and convert that to the cost of fixing those gaps.

How to Get Security Funding

FIELD: I'm going to ask you what could be the most important question. You've decided which gaps you want to fill. How do you take this data you've collected, bring it to senior management, perhaps to the board, and get the funding you need so that you can address these gaps?

GENTILE: You've already, in the step prior, aggregated the data and converted it to a point in which it's hierarchical in nature, meaning you may have started out with 50,000 different findings, you aggregated that into 75 different remediation projects, and you've aggregated that into 10 or eight remediation programs of work. Once you have that, you're really ready to talk to management and show them in an aggregated and hierarchical fashion what the body of work is, as well as what that story is.

Also, remember that along the way you associated scope, schedule and budget to all of those projects and programs of work, so you're going to be able to show management why you should do a specific program of work and a specific set of projects within that, as well as if they choose to do that, how much it's going to cost. It's really the ability to give management good data to make informed decisions.

Key Lessons Learned

FIELD: Mike, you've been at this for a while and you've given some great insight to security leaders. In your experience, what are some of the key lessons learned from organizations that have built successful security programs?

GENTILE: The most important way is to really focus on telling the plot of the story and not telling the end to management. Meaning, don't get associated and get sucked into having an opinion. You've done the process of collecting the data and presenting that to management. Let management make that decision. It's your job to give good data to support a decision. Whatever that decision is, it really doesn't matter when you do it right. The security leaders that I've worked with that have done that are much more successful, because it allows you to stay out of the politics; it allows you to stay out of everything. You're just focusing on the content, the data and presenting that to management. That's your job.

Risk of Not Having a Program

FIELD: A couple of questions to wrap up our discussion, and the first is: What's the risk of not developing a formal security program?

GENTILE: [It's] tied into what we touched on earlier, where right now if you're not fixing or not doing anything, the cost is getting to a point where it's so dramatic [that] it's going to severely impact your business or get you to a point where you're going to go out of business. That's what we're seeing here today. That's going to accelerate as the amount of attacks continue to rise further. There's only so many resources out there right now that know how to fix these problems, so if you're not organized in addressing security and getting the right people, techniques and technologies to do this, your company is going to highly struggle.

Measuring Success

FIELD: The flip side of that: You've developed a formal security program. What does success look like to you?

GENTILE: I think that this is really critical in that many people think that success with a security program is that you are able to fix every finding that you had in your environment, and that's absolutely not true. A successful security program is all about one thing - having a methodical process for getting information to management to make informed decisions and [in] the most efficient way possible to support the business in implementing those decisions. That is it.

I've been in many organizations that have an effective process in place for doing that, and they might not even fix that much. In fact, there's no organization that's going to fix every single finding - even a large percentage of the key issues in their organization - but if they have that ability to look, approach and solve the highest-level risks that present the most risk to the business, they're really going to be in a great position.

I've been in many organizations in situations when they've had a breach or something that they needed to report. I've been in those board meetings before, and I can tell you that the organizations that have nothing in place, are unorganized and are talking about how to address a breach - that board meeting is very different than the board meeting where they may still have a breach on something they didn't fix, but they actively had information and decided to not fix that thing before the breach happened. It's a much better position to be in from a regulatory perspective, as well as from a business perspective.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing databreachtoday.com, you agree to our use of cookies.