CIO Perspective: Breach Happens

Are you still thinking that a breach is something that happens to others, something that you follow in the news? Hopefully at least you are considering a data breach as something imminent and thinking about what to do and where to start. In this article I will ask some thought provoking questions to help you ask the right questions. Taking a step, whatever small it may be, is infinitely better that doing nothing and crossing fingers.

In order to do something about a breach, we have to change our mindset. If you ever studied martial arts in a true dojo, the first thing you learn is to fall. When you are comfortable with falling, you start practicing techniques. This is for a reason: you have to get rid of your insecurity about falling, embrace it and then continue your studies. We have to apply the same mindset with the breaches. If the biggest and most powerful organizations, including governments, armies can’t get away with it, we have to change our mindset. Rather than living with a false sense of insecurity we have to embrace them.

Once we change our mindset, we can begin asking the right questions. What are we trying to protect? What are our priorities? What are we measuring? How are we measuring it? Our replies could be as obvious as protecting our database and mail servers but once we begin scratching the surface, we are very likely to see that there are way too many things to do. Most probably we will see that the operating system and application patches are not up to date at the first place. And once we realize where we are, we may start asking further questions. Maybe we need a huge shift in how we operate: does it make sense to patch, update, upgrade, secure our infrastructure or does it make sense to move to Office 365/Azure? What about our legacy applications? Will we keep them or start migrating/modernizing them?

RELATED:   Types of Data Centers: Steps to the Cloud

Those questions inevitably will question or processes, technology and people. What is the level of awareness in our company both in terms of IT professionals and in terms of users? Are the people in the right mindset about security? What is the pressure of “doing more with less” doing to our employees – are we decreasing the value of their works by our increasing workload demand? How confident are we in our detection, prevention and response procedures? What is our investment on our staff (training, workload etc.) who will go through those procedures? We need to define and update our processes. We need to evaluate our infrastructure and make changes if necessary.

When going through all those evaluations, automation comes as a best friend. In the detection – prevention – response cycle, it will be best to actively search for areas where we can rely on automation. There are certain things computers do much better than us, so why not outsource those things? However, there is a big catch here: automation needs to ease things. It needs to do some mundane tasks people are not good at; such as correlating various logs. If automation does not ease things, then it brings further problems who were nonexistent at the first place. We need to automate where possible, ease the workloads, extend people’s capabilities: focus them on the areas that they create most value by providing them the information and tools they need.

RELATED:   Are Your Employees the Biggest Threat to Your Cybersecurity?

If we are developing software, we have to rethink about testing. We will ask the same basic questions. Why are we testing? Are we testing because we want to show what we did? Are we testing because we want to check usability? Are we testing because we want to see how we match the requirements? If we answer “yes” to all these questions, we also have to answer where security fits. What are our steps to check security? Can we make sure that we embed security in our code? How can we test it? Testing is where we can have more eyes to look at our product and those eyes and minds show us where we can improve. We have to design tests to make us uncomfortable. We need to test internally and externally. Many companies fail to understand the value professional testing brings. With testing we will be able to improve also on the security area, in addition to usability and features.

Finally we need to develop a sound understanding of and response to a breach. What will we do when it happens? Of course, this simple question itself will start an endless conversation. But this conversation will bring many items that everyone will agree without a second thought. What are the business priorities and are these priorities understood by both the users and the IT staff? Are the response procedures clear, accessible and communicated to every employee? Are the capabilities of the employees matched to the priorities? How will the impact be measured? Will outside companies be contacted for assistance? Is informing the media necessary? If yes, who will contact the media? Is there any need to prepare written communication with the media in advance – maybe with the lawyers – so that serious mistakes are avoided in the heat of the incident?

RELATED:   Planning Virtual Desktop Infrastructure? Be Careful With These Mistakes

As we see, once we shift our way of thinking, many steps, conversations, procedures come to the table and the discussions begin. It is, without doubt, way better to change our mindset and bring those questions to the table before a breach happens rather than trying to figure out what to do when the incident strikes – especially if there is also a media side to it. In this mindset, the executives and the board also have to understand the risks and change their mindsets. Their priorities and beliefs have to be challenged without exception.

When walking the breach road we may think that our pace is slow. If we are making small, incremental improvements day by day, then our pace is perfectly OK.

Image credit:

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>