For almost a year now, I have been wearing two different career hats at RealTruck. I was originally hired to be a Linux system administrator, a role I retain to this day. But early last year, it became evident to the leadership of the company that more emphasis on information security (colloquially called infosec) was needed. I was identified as having an interest in infosec, so I was selected by my management to act as the interim security engineer until an experienced engineer could be hired. Upon my selection, I was faced with a big question: what exactly does a security engineer do? In this series of posts, I’d like to explore that question and allow you, the reader, to better understand what it is that your security team (or really any security team) does.
According to a report published by the Software Engineering Institute at Carnegie Mellon University, security teams at large corporations should perform four primary functions (paraphrased slightly): protect, monitor, respond, and govern. As a small company with a security team of roughly three-quarters of a person, some of these functions are more important than others. And some functions are not deemed my sole responsibility but are distributed to other members of the information technology or even development teams. To get a bit more granular, I want to take a look at each of these functions separately, starting with govern.
Within infosec circles, the govern function is well known. However, it often goes by another name: governance, risk, and compliance (GRC). In most industries, there are laws, regulations, or even just best practices that must be followed. Merriam-Webster defines the term compliance as “conformity in fulfilling official requirements.” In infosec, this means creating the necessary documentation for an auditor to evaluate how well a company is following its compliance metrics. At RealTruck, we are required by major credit card companies to follow the Payment Card Industry Data Security Standard (PCI DSS or just PCI, for short). This standard lays out in 12 sections the requirements that we must follow in our day-to-day operations. For instance, physical access to our computer systems is considered a risk, so PCI dictates that we must have some form of accountability at our entrances. This could take the form of security cameras or a receptionist with a sign-in sheet and visitor badges. PCI also requires us to scan our network regularly for vulnerabilities (something I will get into in part III).
PCI is just one of a myriad of regulations. Publicly-traded companies are required to comply with the Sarbanes–Oxley Act (or SOX). Health organizations are required to follow the Health Insurance Portability and Accountability Act (HIPAA). Banks are one of the most heavily regulated of all businesses. You’ve probably experienced some of the controls banks are required to have in place if you’ve ever done online banking. Ever been texted a PIN to type into the site after entering your username and password? This is an example of two-factor authentication, which is considered a best practice for maintaining secure accounts.
All of these are examples of systems compliance, but there’s also the human element. Employees are required to follow these standards as well. However, getting them to do so is another matter entirely. Users are often cited as the number one risk to a corporate network. This is because an uneducated user has a pretty decent chance of accidentally allowing a malicious actor to gain inside access to a corporate network. If you’ve heard of ransomware hitting a company or millions of customer records being stolen, you probably weren’t aware that behind those hacks was a poor user who got duped into clicking a phishing link in an email. These links will then allow a malicious hacker to install software on the user’s workstation and use the trust that this system has with the network to find valuable information. In order to combat this at RealTruck, we perform annual user training that helps employees understand what the threats are and how to protect against them. We also send out monthly tips and security reminders, like the SANS OUCH! newsletter.
Even with all this information about the risks provided to them, some users are either complacent or feel they are above these restrictions. This is why regular auditing is also an important aspect of the govern function. The creation of internal policy documents is usually done by our Vice President of Information Technology (IT) (with plenty of input from Legal). These internal policies are how we implement PCI and even define acceptable processes for such things as adding a new workstation to the network. Each quarter, our Director of IT reviews our documentation to ensure that users were correctly following these policies. It can be a time-consuming task, especially when the policies have not been followed and the proper paperwork/electronic tickets were not created or annotated. But it’s also an effective way to find potential flaws in our network or to identify procedures that are unrealistic. Through auditing, we are better able to refine our security program in a way that is usable and not overly-burdensome to our employees.
The ultimate goal of the govern function is to create and maintain a mindset of security in a company. As you can see, this involves performing a lot of different tasks and having a broad skill set: from technical expertise to business acumen. While the personnel often responsible for implementing the policies that create a culture of security–Chief Information Security Officers or Information Security Managers–are often the object of much cursing within their company, their goal is simply to protect the data within their network and, subsequently, customers like you. In the next article of this series, I’m going to look at the day-to-day operations of those who put the security policies into practice in order to protect their network.
Image courtesy of wp paarz, via Creative Commons license, some rights reserved.