Addressing information security concerns after a product is released can prove expensive, impact development timelines and affect a company’s bottom line. To avoid this - and keep everyone happy - Guy Daubenspeck, CISO at financial services company Kasasa, educates co-workers on the importance of consulting information security from a project’s start. This process proves faster and more economical than tacking on security after a product is already being sold. Plus, the product is more robust when security is included from the start.
Daubenspeck, in this interview, also shares advice on how to avoid clashing with CFOs over budget requests and why corporate boards and other executives are open to hearing about information security’s failures.
You began your career in software development. Why did you move to information security?
There was nothing really altruistic. I didn’t say, “I want to go protect the world from the bad guys.” It was one of those career moves where I just fell into it. I actually worked for one company for about 25 years early on in my career doing software development.
After a while, I got tired of programming and managing programming projects and was looking for something else. I got involved with Tivoli. We had started up a practice within the organization completing and managing Tivoli deployments, and through that process, I got involved with the security piece of Tivoli.
The company I was working with was primarily involved with government contracting, which is cyclical. At the end of every year, the government runs out of money, and you start laying people off. We were looking for opportunities to do something in the commercial sector that would result in steadier income for the organization. We worked with secret and above labs that we secured as part of our government contracts. We were pretty good at it, and so I suggested that we start a security practice.
Originally, we were working with government institutions. As we progressed, we started focusing on those areas within the commercial sector that were more regulated, and at the time, the primary one was the financial industry. They were one of the first to impose strict government regulations. And then also the energy sector, especially nuclear.
We began conducting audits for financial institutions, which I really enjoyed and had an aptitude for. I was constantly learning, and there were constantly new challenges. It was very engaging for me and something I could make a career of, so I continued to grow in the industry.
You have more than 15 years of experience in infosec. What are some of the biggest technical and philosophical changes that you’ve seen around how organizations can protect themselves from adversaries?
Originally when I got into the business, we were intent on protecting ourselves from the perimeter. Everyone was establishing perimeter safeguards, and you felt like you were pretty safe. We were more focused on firewalls and intrusion detection and intrusion prevention. But as our good friends, the hackers, learned to get past those safeguards, we started focusing on encryption of data and protecting the keys. Again, everyone felt safe.
Over time what we’ve all seen and experienced is that most of the attacks originate from the inside out. The attackers are going after our weakest link, which is us. And it’s not just the user community. Anecdotally, at my last job, I had this really sharp security architect. I bet three or four times he picked up malware on his computer because he clicked on something that he just knew was safe to click on, and sure enough, it was malware. We’ve changed our focus over the years to emphasize the end user, user access control, educating our users, and being more proactive in our security awareness training for our users.
Now the industry is actually focusing on the endpoint, our protection mechanisms, and on doing endpoint detection and response. As we’ve seen signature-based protections become archaic and pretty easy to get around now, it’s actually focusing on those endpoints and establishing the right protection mechanisms. But we can’t forget those firewalls and IDS [intrusion detection systems] and IPS [intrusion prevention systems] and encryption of data, but security is, of course, best when practiced in depth.
Could you talk a little more about how you educate users about security?
There’s the traditional security awareness training where we have people sit through a class on an annual basis. We’ve seen that that’s pretty ineffective because people learn how to game the system. We have a very cyber aware user force nowadays. What happens is you do the traditional training, and they try to sit through a 40-minute class. They learn how to know just enough to be able to answer a question or a quiz at the end of the module and can then game the system. They don’t really pay a lot of attention.
I’m working to institute a more topical-based training. As we deal with younger and younger professionals; we are learning that we have to do things in snippets. We’ve got to do things in 140 characters and offer more topical-based training with blogs. If we’re able to teach security tips that the user can use away from the office, that means more to them. We try to do more things that the user can take back home, and they can use on their home PC, that they can tell their spouse about, their kids, their siblings, or their friends. That gets their attention more, so I try to do more than just focus on work training and provide more of an all-around life use case for security.
If you provide some really meaningful topics on a website and associate it with a game, that seems to get more attention. There’s a number of ways that we can attack security awareness training without it just being a once a year, one-hour thing where it’s the same topic that they see year in and year out. Phishing exploits and social engineering training are also great ideas. There are a lot of tools out there that you can use to do phishing simulations, and then when they do click on the link or they open up the attachment, you can provide some immediate, real-time training to them.
What do you wish corporate boards knew about conducting information security?
Board members should understand that any security initiatives within an organization need support from the board. That’s more than just providing resources and money. The entire enterprise needs to understand that the board is supporting these initiatives. Of course, we need resources. We need human resources and financial resources from the board.
It’s also really important for the board to understand, and I’m very lucky here at Kasasa that our board gets it. Too often the board believes, “Well, we hire a CISO, or we hire a director of security, and we hired a security engineer. We’re now protected, right?” It’s really important that the board also understands the need for tools. There needs to be a toolbox that the security team has at their disposal to appropriately do their job.
Maybe the biggest thing the board needs to understand is that whenever there’s a security initiative, there’s a domino effect for the entire enterprise. It’s not just the security team impacted by those tasks and those actions you need to take to secure an organization. It does have an impact across the entire organization. It affects developers, and it affects your system admins. It affects marketing, and it affects the CEOs. There’s an impact to everyone as you move to secure an organization.
How can security practitioners show the board why information security matters?
As a security professional, you can’t run around saying if you don’t do this, the sky is going to fall. You have to demonstrate that you’re considering the business case and be able to relate what you need to do from a security perspective back to the business need – to make money. And you have to demonstrate to the board that the intent is to enable the organization to do the things it needs to do to make money but in a secure manner.
What I always tell every executive that I work around is that we’re not in business to be secure, but if we’re not secure, we’re not going to be in business today. I don’t know if I thought of this originally or if I stole it.
The CISO as a business enabler isn’t usually how others in an organization view security executives.
I’ve seen a lot of really good security people fall on their sword saying things like, “You have to do this in order to be secure.” We really have to figure out what the business’s real goal is and what their problem is. Then we have to allow them to do that, but then we have to put the safeguards around it that will allow them to do it in a manner where we’re not exposing our customers or their customers’ data to risk.
On your LinkedIn profile, you mentioned that security teams should feel comfortable talking about failure as well as success. Why is it important to talk about what happened when things go awry?
When you were young, how did you learn your most important lessons in life? I remember a day when my mom would tell me, okay, you messed up. Now, you need to go out and get the peach switch. You need to go pick it yourself, and cut it, and bring it back in. I’m going to teach you a lesson here. Those lessons are the ones that stuck with me the most through life. I very seldom repeated those.
The bottom line is - if I’m not comfortable going to my CEO, or to the board, or to the CTO and saying, “We’ve had this happen because of a failure in our organization, in our enterprise level of security,” then we’re not going to learn the lesson so that we can prevent it from happening again. If we try to sweep it under the rug, eventually it’s going to catch up to us. We learn our most important lessons through those times where we’ve failed.
Is that a concept that the other executives and the boards can embrace? Are they okay with hearing that security messed up?
Maybe a few years ago they would not be. Now the general philosophy through the security community is it’s not if it’s when, and what do you do about it when you have some form of breach. A breach may not be where you’ve got a hacker inside, and they’re stealing information. A breach may be that one of your users emailed confidential data. There are going to be failures, and everyone must come to realize that. The threats that we face on a day-to-day basis, they increase far more than the protection mechanisms that we put in place on a daily basis.
In the security community, we’ve realized that we’re always going to be one step behind. It’s always a game of catch up. When you’re playing catch up all the time, you’re going to have mistakes. That’s something executives at all levels have learned, sometimes very painfully but sometimes just through anecdotal evidence of what’s happened to others. You cannot look around now without knowing some large organization that’s had a breach. Those large organizations often have a really huge security budget, and they still have incidents. If someone is really looking at the realities of life right now, they definitely are going to be comfortable with being informed of when there’s a failure; they’re going to be appreciative of that.
There seems to be a constant debate on whether information security should report to a CIO, or a CTO, or a CISO. What’s your take? What should that reporting structure look like?
Reporting to a CIO or a CTO directly, I understand the merit of that: you can have some synergy between other technology groups. However, that goes back to the old axiom of the fox guarding the hen house. That CIO and CTO’s primary motivation is to get product out, to get technology out, or to enable the business, and security can sometimes be an impediment to that. We need to all understand there may be some conflicting goals between the two, and more than conflicting goals, there needs to be a clear reporting structure. I just talked about the ability to go and report failures that can be inhibited somewhat if that reporting line is not to a higher power.
Ideally, the CISO should report directly to the board, however, if the CISO reports to the CIO, CTO, CFO, or CEO, the most important thing is that the CISO still have opportunities to report directly to the board and that the reporting is unfiltered.
What do you wish the finance departments knew about carrying out information security?
I have never really had a problem dealing with CFOs; the reason is the way I approach a CFO with a budget request by just laying out the risk. I like to do everything risk-based. Even in my budget discussions with the CFO, or the CEO, or the leadership team as a whole. The way you make your case is by doing a high-level risk assessment, and identifying where you have areas of risk. Lay out the possible ways that you can go about mitigating that risk, and then what the residual risk is going to be to an organization based on the solution that you choose to mitigate that risk. Then, ultimately, tie that back to what the expected loss could be based upon a risk that you’ve identified being exploited, and then you tie that back to the organization’s appetite for accepting that risk.
Ultimately, when you’re talking about a CFO, of course, it’s all related to finance and money. If you can show that the tool you need to buy, or the person you need to hire, can tie back to it being less of a financial risk to spend the money, then, typically, you’re going to get that money.
How can innovation be balanced with security?
The best way to balance innovation with security is by educating the business on the importance of security being involved in those innovations from when they’re a concept. If you start to involve security when you first think of the idea, then security can be a partner instead of an impediment. If we can be a partner with the organization as we go through innovations, it’s so much easier to do good security. It affects the bottom line. It affects the budget. It affects development timelines. There’s just that cost from idea to deployment that is reduced if security is a part of it from the very beginning. When you’re defining your requirements, you’re defining your security requirements as well. It is so much more economical, and it is such a better solution that you have in place in the end.
When you have an organization like Kasasa or 99 percent of the organizations out there developing technology solutions, typically, they decided at some point to bring in a security department. So the security department comes in, and you do your analysis to determine that you need to go back and retrofit security into a lot of different things. That’s a very expensive concept, and it’s very difficult. It affects timelines, and it affects your ability to be innovative.
The one thing I would coach everyone on is to involve security. Make them your partner in a development effort or when you’re innovating a product, or you’re changing the way you deliver things. Just make security a partner from the beginning, and everyone will be happier.