TL;DR: This post is long and there’s no way around it; security is complex and varied. Fundamentally, security breaks down into 8 verticals covering everything from physical security to privacy to engineering to incident response. Don’t expect one person to get it all done, and be concerned if your CISO doesn’t have something to say about each of these.
What does a Security team do anyway? They just make sure our applications or servers don’t get hacked right? Can’t we just have one or two people and have them cover all of the bases? There can’t be all that much to do!
Let me start by saying that each of these summaries below are gross oversimplifications of what each area does, but it establishes an overall context. I will also say that one should not be deterred from understanding security and risk management because they are at a smaller organization. Rather take it should inform conscious decision making around which disciplines are not being addressed and identifying that as a risk to be revisited at a later time.
Security is shorthand for Security and Risk Management. Security’s responsibility in a company is to help the business measure risk, and inform the business about how it can remain nimble without taking unnecessary/uninformed risk. In order to do so, security has to cover a wide swath of topics ranging from how not to die working for the company to protecting the company from risk. Obviously, these domains will be covered to varying degrees and depth by any given organization, but the majority should have some form of attention paid to it.
Organizations can also make the conscious decision not to cover a certain area, and we will talk in another post about the risks the organization is accepting by doing so.
I consider security to be the Liberal Arts of professional domains as it touches everything from engineering to psychology. In another post will cover how you staff for these disciplines, and then it will become obvious why a two person team cannot cover the breadth and depth of the responsibilities.
So let’s start to break it down. Here’s a helpful map of what we’re covering:
Physical Security and Life Safety
Within the areas of physical security, we have all of those badges that everyone loves so much and access control. To supplement the access control, we then layer on video monitoring through Closed Circuit Television (CCTV) to monitor the environment. It’s one thing to know that a door was forced open, it’s another to say who or what did it.
Another imperative area to have covered is fire and life safety, which also covers other types of evacuations should you be located in a target rich area (e.g. NYC) or a high profile building. This area will ensure that you have Automated External Defibrilators (AEDs) in the event of a heart attack, training employees in CPR and first aid, organizing evacuation drills, working with the landlords to implement fire safety teams, active shooter plans, etc. Essentially, fire and life safety takes the role of “something terrible just happened putting lives in danger, now what?”
Depending on the organization, you may then expand into other areas of physical security such as Situational Security or having a Global Security Operations Center (GSOC). The GSOC will be responsible for monitoring employee travel and ensuring their safety should they be put in harm’s way. This team would also manage things like executive protection, kidnap and ransom incidents, etc.
Investigations
No one likes to say that they don’t trust their employees, but no matter what your company does, there will come a time when an investigation must be performed. The investigation can be triggered internally, or it could be the result of outside pressures like a subpoena or warrant. Regardless of the driver, the organization should want the investigation performed in a professional, organized, documented, admissible, and repeatable way. We will encounter these qualities in other sections, but this is a key concept which sometimes means hiring outside specialists if your organization does not have the required staff.
Back to the whole “we trust our employees”. You will inevitably, at some point, worry about an Insider Threat. This is the type of investigation that needs to be performed thoroughly and with the tight collaboration with legal counsel and human resources. This is where you hope all of the other risk management and technology put in place gives you sufficient visibility to quickly ascertain whether or not there is a threat.
eDiscovery speaks for itself. If you are involved in legal proceedings, you may need to retain the electronic documents related to the request. This is where I remind you that every email, text message, instant message, etc is eligible for discovery (investigators love this stuff). eDiscovery may be an area that you outsource in order to ensure that what is provided is accurate and admissible. You will see some parallels in statements to when we get to forensics and incident response.
Law enforcement liaisons will be relevant depending on your line of business. If others are transacting on platforms that you operate then you should expect to receive subpoenas or warrants from law enforcement. More often than not, this will involve a combination of your CISO’s organization and legal. It is important these requests be responded to in a timely manner and consistently so as not to implicate your own business.
Privacy
Privacy is a topic that I grew to appreciate during a few of my roles. It is fraught with complexity and usually involves heavy Security and legal components. This is not solely a legal problem as there are many technical and procedural nuances that can help limit risk.
First, there is the regulatory component which demands compliance. Here you can think of your best friend, Global Data Protection Regulation (GDPR), but there are any number of local regulations that need to be taken into account around the world. For example, a violation of privacy laws in India would require that the executives of the company be personally liable for fines or other punitive actions. Any time the business is planning to embark on doing business in a new region (locally or internationally), privacy regulations should be examined by your CISO’s organization.
Performing proper data inventories of all Personally Identifiable Information (PII) will allow you to more properly plan for future expansion or response to new regulations. Understanding things like toxic combinations of data from different repositories becomes essential. Your Security organization should run this as part of their overall asset inventory to also be prepared for incident response.
Finally, there is the reporting component to privacy – what to report, how, when, why, and where. Some jurisdictions consider your zip code to be PII while others won’t bat an eye. How do you know where you need to report an issue if you do not know your areas of possible impact for reporting?
Governance, Risk, and Compliance (GRC)
Now we start getting into the areas that company leadership more normally associates with the CISO if the company is regulated or is seeking certifications of some kind. GRC is an area that I would consider to be the foundational elements of a true Security and Risk Management program. It is easy to jump right into technical controls, but if you don’t understand what you’re protecting and to what levels they need protecting then the Security team is making assumptions. GRC is the primary interface into helping the leadership team understand risk.
For the sake of brevity, we will group Policy and Procedure together. I will assume that you know what Policies and Procedures are at this point. We will speak more about them later. But let me say just one thing at this time: If you have an information security policy that is more than 20 pages that you expect your employees to read then please revisit it.
Third Party Risk is the thing that everyone spends a lot of time on doing Due Dilligence Questionnaires (DDQs). The imperfect science where you measure your vendors based on what one must assume are heavily biased partial representations of the truth. The end goal is to be able to state to your customers, regulators, and auditors, that you care about the security of your third parties and have some way of holding them accountable. More on this in other posts.
GRC is where your Security Committee (and you should have one) enters into the picture. The Security Committee helps to inform a group representative of all facets of the business about the Security organization’s stance and progress. It is where risks are discussed, the risk and controls library is curated, and oversight is provided. The Security Committee also provides an overall feedback look to the Security team of new business risks or initiatives that should be taken into account.
While vulnerability management has strong technical components, how vulnerabilities are cataloged and tracked usually sits under GRC since the vulnerabilities need not all be technical in nature. Vulnerability management is where you understand open exposures to the business and how they are being mitigated, avoided, or accepted.
This then leads into Exception Management since there are always exceptions to policies and procedures. GRC is responsible for cataloging the exceptions and also tracking the resolution/closure of the exceptions.
I can’t believe we’re only about half way through describing the security program. Hopefully at this point you are coming to realize how broad Security and Risk Management is, and why you should not expect it to be fully performed by two or three people within your organization. I’ll let you step away for a bio break or sustenance before we continue…….Ok…..ready to continue? Here we go into the technical areas…..
Application Security (AppSec)
Now we get into what many see as the focus of all Security programs, Application Security (AppSec). This is where the architectures, code reviews, scanning, and bug bounties occur so let’s break it down. I will also say that AppSec is one of the areas within Security that should be a business enabler whether it’s building more secure products or helping the business get to market faster by building better products quicker.
Architecture is the component where we define what is being built before it is built – very analogous to the real world of erecting a building. Let’s determine what data is flowing where, whether it’s encrypted in motion or at rest, and what happens to the data once it flows to its destination in very broad terms. Would you start building a house if you didn’t have any plans? No? Neither would I. Without security architectures your program is already behind the proverbial 8-ball.
Once the architecture is laid out, it’s time to write some code and then have it reviewed by Security. We start with Embedded AppSec where AppSec works directly with the engineering teams to ensure that they’re writing good code and tools from the outset. The earlier we catch issues, the less work it is to fix them. Once the code is written, it’s then time to review the code for any potential issues; note that these reviews are usually a combination of manual and automated tests.
Now we get into the mode of once the code is released or about to be released. This is where we perform our penetration testing and start up our vulnerability scanning of the software. Ideally some of this happens before code walks out the door, but it’s better late than never! The key here it to make as much of this as automated as possible so that you can catch things reliably and quickly. All too often these tests are relegated to annual scans of your applications or an outside code audit. I like to recommend that one does use outside firms for this work at least annually, and switch vendors every 1-2 years. The reason for both is to get a fresh perspective since code audit and penetration testing is as much art as science, and everyone has different specialities.
Better yet is to leverage the gamification of Bug Bounties to have constant attention paid to your applications if they’re available to the internet. Bug Bounties are interesting because they allow for continuous testing of your products by security researchers with a variety of skill sets. I would strongly recommend the use of a vendor to run your Bug Bounty as it is a full time job managing the submissions, and one must have a consistent process for handling them. On the whole I have seen great PR value, education value, and test coverage value by leveraging these programs.
Engineering
We now enter the realm of how we protect ourselves from a technical perspective. This team is often focused on the majority of the build vs. buy decision making. There is a wealth of security products out there to purchase as point solutions or platforms, open source tools to use, or you may choose to build some yourself. Some of the greatest innovation comes in the form of open source tools and projects to help secure your company and your products. They key is to maintain a balance between the build vs. buy.
The Engineering team will be responsible for implementing the technical and detective controls in the information security program. They will also be the ones responsible for a good amount of care and feeding of those tools and products. These engineers need to think a bit like the malicious actors they are trying to stop, and only then will they be effective at building a world class gauntlet full of walls, boobytraps and tripwires.
Analytics and Tool Development go hand in hand in the next phase of security Engineering. Tool Development can be defensive, offensive, or detective in nature and it needs to be a conscious decision made by qualified professionals. Just having an engineer slap together some code and make it run is a recipe for long term disaster and poor maintainability. Out of those tools comes the data and analysis that then gets put in front of the operations and investigations teams to allow them to do their jobs.
Operations
We are almost at the end of our journey through the breadth and depth of security programs. I apologize for how long this has been, but this is even still just scratching the surface of a security organization’s responsibilities.
Operations is where the rubber hits the road. It’s the room full of screens that executives love to parade customers in front of showing “Pew Pew Maps” of attacks happening in real time (please never force your operations team to have those maps on the screens – they’re useless and make security professionals sad).
Just like in any other discipline that involves a combination of lower level analysts through specialized investigators divided into tiers. Tier 1 is usually low level personnel or potentially an MSSP (Managed Security Service Provider) or even advanced analytics of sorts. From there, triaged alerts are bubbled up to Tier 2 and Tier 3 analysts who can further investigate, enrich, and correlate the data. The key here is to ask meaningful questions and preserve that knowledge for future investigations.
Tier 3 starts to meld into Digital Forensics and Incident Response (DFIR). DFIR is a whole science in and of itself that would take an entire book to explain (and there are many books on the topic). These are trained investigators who can piece together the scene of the crime. This is a discipline that I usually consider to be best outsourced to a specialist firm on retainer unless if your organization is of the size that daily incidents and events occur. DFIR professionals require constant tool sharpening, and need to be performing investigations. Do not think that a highly skilled DFIR professional will be satisfied doing Tier 1 triage until “The Big One” hits. By the time that happens, they will have lost all of their skills or quit.
Testing
Finally there’ the sexiest security jobs of them app – red teaming. Red teaming refers to a team of individuals (usually outsourced) who are given a no holds barred license to attack the company; this could include everything from phishing attacks, to physical social engineering, to hacking your sites. This is the testing your systems and applications need to survive, and that your operations team (also known as Blue Team) need to be able to detect. Good luck!
Conclusion
As I mentioned previously, I apologize for the length of this post, and hopefully you made it all the way through. This tour has ideally given you an appreciation of the breadth and depth of what a security program does within an organization and what you should be looking for from your CISO from a content perspective. Following sections will focus on how we measure our CISO against these disciplines and whether you are left uncovered.
I will caveat all of this by saying that one does not need to do everything here. It always depends on your business, the maturity of the company, and the desire to invest. However, what executives are responsible for is understanding what they are not going to do and the risks they are accepting. For example, it is perfectly acceptable for a startup to have delegated a few security jobs out to the development teams or security-minded folks, but there comes a time when someone needs to bring the program together. This can be driven by size, complexity, or regulatory requirements.
