Information Security A Practical Guide: Bridging the gap between IT and management (2015)
CHAPTER 6. GETTING BUY-IN FROM YOUR PEERS
Rationale: Lots of books discuss how to get management buy-in. In the context of this book you already have management buy-in because they’re either reading this book or you’ve been employed by management and they’re paying your wages. Often it is other IT professionals who need to be won over. They often see security as a barrier and look to go around that barrier rather than engage properly with security. Any good security professional must have buy-in from their peers, as without it you cannot implement effective security controls.
Content: This chapter discusses how to get buy-in from your peers so they understand the security risks to their system and how you can help them. This can be done by showing and demonstrating to them penetration test results; these people are technically minded so reproducing the risk in practice really helps. Secondly, these teams have sat through many (probably annually) boring and generic security awareness presentations. Instead, tailor these presentations to them, as this shows you understand their area and, their risks and problems. This approach will increase engagement during the presentation and outside during day to day work. I also discuss some of the most common IT teams you will find in a business and advise on how to better engage with them and the value you can offer.
Chapter Overview
Having buy-in from your peers benefits everyone. There’s nothing worse than a project being considerably delayed or even cancelled because of an early decision that later turned out to be a bad one. The earlier in the project everyone gets together and considers the security implications, the better. Gaining this inclusion can only be done through buy-in from your peers. Achieve this and you will be included earlier in projects.
Gaining this buy-in is not a quick or easy process. Often security is seen as a blocker or a necessary evil at the end (some organisations are better than others). The best way to build relationships and get buy-in is to include people in security decisions. When people know that their input is valued and that they can help steer the security of the project they are more likely to buy in.
This chapter discusses techniques I have used to get buy-in from my peers. It explains the usefulness of each technique and how it can be implemented. As with security controls I recommend using more than one technique as success is more likely. It also means you engage with technical and non-technical staff members. Also included are some of the key teams needed to deliver and manage a secure project.
Objectives
In this chapter you will learn the following:
• How to get technical teams to attack and understand the system
• How to raise security awareness
• How to engage with specific peer groups.
Points of Contact with your Peers
Scoping penetration tests
The penetration test is often one of the most interesting parts of the security assurance process for technical team members. This is due to two key aspects: the competition of whether someone else can break the system we have built, and the certain attraction of ‘hacking’ and breaking into systems.
The first step when scoping a penetration test should be asking the technical team how they would attack the system. No one is going to know the system better than the people who built it, so by documenting how they believe it can be attacked we can ensure not only that the test is more thorough but also take the first step of engagement. I recommend holding a workshop, put the high-level designs on the wall, and work through each component, discuss its weaknesses and document them. These attacks can then be included in the full penetration test (Chapter 9).
Penetration test results
Penetration test results are great for not only engaging with your peers but also learning. Penetration tests are technical processes; even when they document a security hole that they have found, only the technical team will truly understand what is happening in the underlying system. The technical team is usually responsible for fixing the security holes, so we need to ensure they fully understand the attacks. I recommend holding a meeting with the team to discuss the report. The technical team will understand the system they have built but it is unlikely that they will understand all the attacks detailed in the document. Even better, if your budget allows, arrange for the penetration test team to hold a workshop with the technical team. Have them demonstrate each attack showing the code and scripts they used, allowing the technical team to see the attacks and work with the penetration test team to analyse each finding, this will further the team’s understanding of the security controls in the system and of security in general. Also, this kind of workshop can be fun, as people enjoy the technical challenge.
Security awareness
Security awareness is typically the most common way of interacting with staff but often these annual awareness sessions are death by PowerPoint and really of little use. When I run an awareness session I look back at the previous 12 months and look at security incidents that have affected the organisation and the stories that have been big in the media. The most important part of awareness is making the information useful to staff, something they can apply in their day to day roles. Sometimes when working I’ll be stopped in the corridor by a peer who mentions a recent security breach in the news; they want to know more and if we are protected. Another useful inclusion is to discuss the threat landscape and the current threats to the organisation. Get peers involved, show them the real risks to the organisation and show them what is currently worrying you as a security professional.
Security awareness doesn’t have to be an annual event where you save a year’s worth of learning for one presentation. Smaller weekly or monthly newsletters can be very effective in keeping staff up to date, especially on current news stories or even recent security incidents that have occurred in the organisation. These events remind people of their responsibilities. For example, in my organisation when we see an upturn in the amount of phishing email being received by staff we issue a newsletter to all staff explaining what’s going on. We direct them to the policy and processes to manage phishing emails and try to safely include examples of the actual emails being received by the organisation.
Another great way to raise awareness is with project awareness sessions. At the start of a project make sure everyone has the same amount of baseline information. If you can conduct a quick and dirty risk assessment (Chapter 5) early on in the project then you can use that as the basis for an awareness session. Conducting these sessions is also a great way to introduce yourself to the project team and show them that you are adopting a proactive approach to security. Attendees can raise their concerns so that you may consider them early.
System operating procedure creation
System operating procedure (SyOps) documents are a great place to put in writing how staff will properly and securely operate a system. If you create SyOps without consulting those who it will apply to then you’re likely to upset a lot of people and achieve the opposite to engagement. However, if you can bring the knowledge of those who it will apply to on board then not only will you create better, more secure SyOps but also people will be more inclined to actually follow them. In the creation of a new SyOp first conduct a risk assessment in partnership with the people who it will apply to. Take the time to understand how they work and show them the risks (if any) posed by their current working practices. These risks can then drive discussion about how things can be done better. Allow those who the procedure applies to to develop the procedure by letting them make the decisions on how they want to work. If the group doesn’t agree or understand the controls then they are unlikely to follow them.
How to Engage with your Peers
Software development
The software development team are likely the most technical team, and used to creating innovative solutions to problems. They typically enjoy the challenge of learning new technology. However, often they dislike having to follow formal and administrative processes.
The best way to engage with software developers is to work with them on the more technical aspects of security. Including them in the penetration testing process is a great way of harnessing their creativity and technical understanding while ensuring the effectiveness of the penetration testing process.
I have taken this a step further and worked with software developers to help them create their own security testing scripts to penetration test their own code. If you do go down this route then I still recommend procuring a third-party penetration tester service to verify the results.
Help Desk
The help desk is responsible for handing day to day user support, and beyond technology they are often the first team to notice if a system is under attack. This is because often the users of a system will notice if something is wrong, for example slow loading, account changes or even missing data; the user will then contact a help desk for support. The help desk has an overall view of a system’s performance and its current state, which means if a high number of users report a slow system then there is probably something wrong and it needs to be investigated. The key question for the help desk is whether the current issues are part of a much larger security problem or whether users just do not understand the system.
Help desk staff are usually not the most technical of people. Their skills are in communication and remaining calm even when confronted by the angriest of customers. Because of this I recommend going through security awareness processes with them. By ensuring they understand the threat landscape to the organisation and current security trends they are more likely to spot a security breach and escalate than simply put it down to user error. A good strategy is to pass them small amounts of security awareness information on a regular basis. This ensures security is always at the forefront of their work and also that they can better serve customers.
Business Analysts
Business analysts are often the least technical members of the team but typically understand the most about the business, and possibly the users depending on their roles. Business analysts help us understand our users, so it’s important they are engaged with security to build that relationship. Another key area of engagement is that they can help manage user expectations. For example, often customers like links to be sent in emails, but we all know that scammers use emails with links to infect users or even direct them to a spoof web page to steal their credentials. If we ensure business analysts understand some of these common attacks, we can better work with the users to strike a balance of security and usability.
For business analysts I recommend not only general annual security awareness sessions but also specific awareness sessions for the project they are about to undertake. Any sort of awareness needs to focus on the process side of security. I once delivered a session to business analysts on the sensitivity of different data and how the aggregation of lots of small data leaks can result in a large data breach. The aim of the analyst shouldn’t be to solve security problems, just ensure the topic is discussed and considered through the analysis process.
Management
If you find yourself in an organisation that does not have a high regard for security then you’re never going to change that without buy-in from the top. Unfortunately, if the organisation’s culture isn’t security conscious then it is probably management that have fostered this negative culture. Opening their eyes to the risks that they face will not be easy, but a good start would be to use some fear, uncertainty and doubt (FUD). These are scare stories, often used effectively by sales people to sell a new secure IT product. Choose stories that have recently been in the media, stories about security breaches and other similar events. Break down these stories into plain and simple English, explain how they impacted the business and the cost and reputational damage that they caused. If you have recently undergone a penetration test and have similar examples that exist in your own systems, even better. Showing them that your own organisation is equally as vulnerable should force them to take security more seriously.