Creating or improving upon a security program can be a daunting task. With so many facets to consider, the more initial thought and planning that is put into the creation of this program, the easier it will be to manage in the long run. In this chapter, we will cover the skeleton of a security program and initial administrative steps.
Do not fall into the habit of performing tasks, going through routines, or completing configuration with the mindset of, “This is how we’ve always done it.” That type of thinking will only hinder progress and decrease security posture as time goes on.
Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.”
Grace Hopper, “The Wit and Wisdom of Grace Hopper” (1987)
We recommend that when creating the program, you follow this chapter in order. While we attempted to group the remaining chapters accordingly, they can be followed as best fits a company.
It is not necessary to reinvent the wheel in order to lay out the initial groundwork for an information security program. There are a few standards that can be of great use that we will cover in Chapter 8. The National Institute of Standards & Technology (NIST) has a risk-based cybersecurity framework that covers many aspects of a program. The NIST Framework Core consists of five concurrent and continuous functions—Identify, Protect, Detect, Respond, and Recover. When considered together, these functions provide a high-level, strategic view of the lifecycle of an organization’s management of cybersecurity risk. Not only will a framework be a possible asset, so will compliance standards. Although poorly implemented compliance standards can hinder the overall security of an organization, they can also prove to be a great starting point for a new program. We will cover compliance standards in more depth in Chapter 8. While resources like these can be a phenomenal value add, you must always keep in mind that every organization is different, and some aspects covered may not be relevant (there are continuous recurring reminders of this throughout the book).
As with many other departments, there are virtues in having the correct staff on the correct teams in regards to security. Open cross-team communication should be a primary goal, as without it the security posture is severely weakened. A good security team consists of the following:
A chief information office (CIO) or chief information security office (CISO) will provide the leverage and authority needed for businesswide decisions and changes. An executive team will also be able to provide a long-term vision, communicate corporate risks, establish objectives, provide funding, and suggest milestones.
Many organizations already have a risk assessment team, and this may be a subset of that team. In the majority of organizations, security is not going to be the number-one priority. This team will calculate risks surrounding many other areas of the business, from sales to marketing and financials. Security may not be something they are extremely familiar with. In this case they can either be taught security basics case by case, or a security risk analyst could be added to the team. A risk framework such as the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework can assist with this.
The security team will perform tasks to assess and strengthen the environment. The majority of this book is focused toward this and the executive team. They are responsible for daily security operations, including managing assets, assessing threats and vulnerabilities, monitoring the environment for attacks and threats, managing risks, and providing training. In a large enough environment, this team can be broken up into a variety of subteams such as networking, operation, application, and offensive security.
It is always a good idea to have a system of checks and balances. This is not only to look for gaps in the security processes and controls, but also to ensure the correct tasks and milestones are being covered.
The unknowns in any environment are going to be scary. How will you know what level of success the program has had without knowing where it started? At the beginning of any new security program or any deep dive into an existing one, a baseline and discovery phase should be one of the first and foremost tasks at hand for all teams. Throughout this book we will cover asset management several times in different ways. The baseline of the security of the organization is just another step in that management. Items that should be gathered include:
Policies and procedures
Endpoints—desktops and servers, including implementation date and software version
Licensing and software renewal, as well as SSL certificates
Internet footprint—domains, mail servers, dmz devices
Networking devices—routers, switches, APs, IDS/IPS, and Network Traffic
Logging and monitoring
Ingress/egress points—ISP contacts, account numbers, and IP addresses
Assessing threats and risks will be incredibly different for each and every organization. Each internal and external footprint is unique when combined with the individual infrastructure involved. Assessing these includes both a high-level overview, as well as in-depth knowledge of assets. Without the knowledge of the threats and risks your organization faces, it is more difficult to custom fit technologies and recommendations to provide a suitable defense. Risk management is often split into four steps: identify, assess, mitigate, and monitor.
Organizations should be concerned with a large amount of threats and risks that will cross industry verticals. Focusing on industry trends and specific threats will allow the security program to be customized and prioritized to become more efficient. Many organizations have put very little thought into what threats and risks they face on a day-to-day basis, and will continue to do so until they fall victim to them. Invaluable resources in this case are available through Information Sharing and Analysis Centers (ISACs), which are brought together by the National Council of ISACs to share sector-specific Information Security. “ISACs collect, analyze and disseminate actionable threat information to their members and provide members with tools to mitigate risks and enhance resiliency.”1
Not only should industry-specific threats be identified, but also overall trending threats such as malware, ransomware, phishing, and remote exploits. Two very important places to make note of are the OWASP top 10 and the CIS 20 (previously known as SANS Top 20) Critical Security Controls. Every organization can make use of both these and the standards outlined by the Cloud Security Alliance. The majority of the items on these lists will be covered in more depth in this book, but keeping up-to-date with them year to year should be a key part of any strategic plan.
After the potential risks have been identified, assess these risks to determine if they apply to the particular environment. Tasks such as internal and external vulnerability scans, firewall rule audits, and asset management and discovery will lend a larger picture to the type of overall risk exposure.
Mitigation of risks is the meat and bones of why we’re all here; it’s also the purpose of the majority of this book. Options include avoiding, remediating, transferring, or accepting the risk. Some examples:
Kate knows that a certain endpoint has no access to other endpoints and runs a third-party application. This application has a low-risk vulnerability that is required for it to function. While nothing at that point can be changed or remediated with that vulnerability, the risk is low enough to accept.
You should only accept risk as a last resort. If a risk ever makes it to this point, request full documentation from third-party vendors and the executive team, as well as documentation of processes that have been attempted prior to making this decision. Add at least an annual review of any accepted risks to ensure they are revisited accordingly.
Keep track of the risk over time with scheduled quarterly or yearly meetings. Throughout the year, many changes will have taken place that affect the amount and type of risk that you should consider. As a part of any change monitoring or change control, determine if the change is affecting risk in any way.
Once threats and risks have been identified and assessed, they must also be prioritized from highest to lowest risk percentage for remediation, with a concentration on ongoing protection. This doesn’t always have to be an expensive venture, however. A large amount of defensive mitigations can be performed at little or no cost to an organization. This enables many opportunities to start a security program without having a budget to do so. Performing the due diligence required to get the program off the ground for free should speak volumes to an executive team.
Do not always take vendor or third-party advice for prioritization. Every environment is different and should be treated as such. Prioritize tasks based on the bigger picture when all of the information has been collected.
This book wasn’t written to be a sequential list of security tasks to complete. Prioritization can differ greatly from environment to environment. Just remember, if the environment is already on fire and under attack, don’t start by creating policies or reversing malware. As a fire marshall, you shouldn’t be worried about looking for the arsonist and point of origin when you haven’t even put out the fire yet.
Milestones will take you from where you are to where you want to be. They will be a general progression on the road to a secure environment. This is heading a little into project manager (PM) duties, but in many cases companies do not have dedicated PMs. Milestones can be broken up loosely into four lengths or tiers:
The earliest milestones to meet should be quick wins that can be accomplished in hours or days—high vulnerabilities such as one-off unused endpoints that can be eliminated, legacy devices that can be moved to a more secure network, and third-party patches all could fall under this category. We will mention many free solutions as the sales process can take a significant time to complete.
Higher vulnerabilities that may need to go through a change management process, create a change in process, or be communicated to a significant amount of people might not end up in Tier 1. Major routing changes, user education implementation, and decommissioning shared accounts, services, and devices are all improvements that also require little-to-no-budget to accomplish.
Vulnerabilities and changes that require a significant amount of planning or that rely on other fixes to be applied first fall into this tier. Domain upgrades, server and major infrastructure device replacements, monitoring, and authentication changes are all good examples.
Many times a milestone may take several years to accomplish, due to the length of a project, lack of budget, contract renewals, or difficulty of change. This could include items such as a network restructure, primary software replacement, or new datacenter builds.
It is helpful to tie milestones to critical controls and risks that have already been identified. Although starting with the higher risks and vulnerabilities is a good idea, they may not be easy fixes. In many cases, not only will these items take a significant amount of time and design, but they may require budget that is not available. All aspects need to be taken into account when creating each tier.
Use cases are important for showcasing situations that may put critical infrastructure, sensitive data, or other assets at risk. Brainstorm with data owners and leaders to plan ahead for malicious attacks. It is best to come up with around three different use cases to focus on in the beginning and plan on building security mitigations and monitoring around them. Items such as ransomware, DDoS (Distributed Denial of Service), disgruntled employee, insider threat, and data exfiltration are all good examples of possible use cases. After several use cases have been chosen they can be broken down, analyzed, and correlated to each step of Lockheed Martin’s Intrusion Kill Chain.
The Intrusion Kill Chain, sometimes called the Cyber Kill Chain, is “a model for actionable intelligence when defenders align enterprise defensive capabilities to the specific processes an adversary undertakes to target that enterprise.” It is composed of seven steps as described in the Lockheed Martin whitepaper:
Reconnaissance: research, identification, and selection of targets, often represented as crawling internet websites such as conference proceedings and mailing lists for email addresses, social relationships, or information on specific technologies.
Weaponization: coupling a remote access trojan with an exploit into a deliverable payload, typically by means of an automated tool (weaponizer). Increasingly, client application data files such as Adobe Portable Document Format (PDF) or Microsoft Office documents serve as the weaponized deliverable.
Exploitation: After the weapon is delivered to victim host, exploitation triggers intruders’ code. Most often, exploitation targets an application or operating system vulnerability, but it could also more simply exploit the users themselves or leverage an operating system feature that auto-executes code.
Command and Control (C2): Typically, compromised hosts must beacon outbound to an internet controller server to establish a C2 channel. APT malware especially requires manual interaction rather than conduct activity automatically. Once the C2 channel establishes, intruders have “hands on the keyboard” access inside the target environment.
Actions on Objectives: only now, after progressing through the first six phases, can intruders take actions to achieve their original objectives. Typically, this objective is data exfiltration, which involves collecting, encrypting and extracting information from the victim environment; violations of data integrity or availability are potential objectives as well. Alternatively, the intruders may only desire access to the initial victim box for use as a hop point to compromise additional systems and move laterally inside the network.
This whitepaper has a good amount of information that can be used for creating use cases as well.
Table 1-1 is an example of a step-by-step kill chain use case we’ve created for a ransomware attack.
|Kill chain step||Malicious action||Defensive mitigation||Potential monitoring|
|Reconnaissance||Attacker obtains email addresses, technologies used, and creates an organizational profile based on that information.||
Create policies around sharing internal information on sites such as LinkedIn or using corporate email addresses for nonbusiness use.
After a major breach has been seen on the news run a password reset. Even though they shouldn’t, employees will reuse passwords for other services and sites.
Have corporate emails been seen in breaches elsewhere? How many emails are found with OSINT?
Attacker creates a malicious exploit to send to the victim, or uses a current exploit.
Knowledge and awareness of threats currently being used by attackers will allow for better constructed and tuned mitigation steps.
A user receives a phishing email.
Assess which attachment types are needed in the organization. File types such as .js can be extremely harmful and are rarely exchanged from external sources.
Implement mailing blacklists and greylists such as Spamhaus and dnsbl to block known malicious mail servers.
Instill the idea of “trust but verify” to your users.
Filetypes of a certain size known to be malicious and associated with ransomware. (Flag .scr files over 22 MB and .js over 15 MB.)
Disable macros and malicious filetypes via group policy.
Ensure any endpoint protection is up-to-date and installed.
Use proxies or IDS (if cleartext) to monitor for known deobfuscation strings.
The payload is executed on the end user’s device. (Lucky, Cerber, and CryptoWall use the built-in Windows Cypto API to handle the encryption.)
Keep backups (that are not permanently attached) so that encrypted files can be restored easily.
Depending on OS, you can use “filesystem firewalls” such as as Little Flocker to permit access to files on per-process basis. That means that you can permit read access to MS Word, but not IE, for example.
There are experimental techniques that can be used to block crypto-based ransomware (e.g., Decryptonite)
High increase in Windows Crypto API over short amount of time.
Excessive numbers in a domain or low % of meaningful strings in domain.
|Command & Control (C&C)||
The ransomware contacts a C&C server on the internet to transmit the decryption key.
Implement sinkhole DNS and autoblock outbound connections to known malicious IP addresses.
Connection to known C&C servers.
|Actions & Objectives||
The malware starts encrypting the files on the hard disk, mapped network drives, and USB devices. Once completed, a splash screen, desktop image, website, or text file appear with instructions for the ransom.
Implement Honey Directories—the ransomware goes into C:\$$ it sees another $$ directory, when it goes into C:\$$\$$ it sees another $$ directory, and so on.
Advanced file auditing can be enabled for alerting on an extreme increase in filesystem changes.
Many different defensive mitigations can be added at each step of the kill chain for an overall decrease in risk at each layer.
Following the creation and implementation of security controls around use cases, the testing of tabletop exercises and drills can serve as a proof of concept. A tabletop exercise is a meeting of key stakeholders and staff who walk step by step through the mitigation of some type of disaster, malfunction, attack, or other emergency in a low stress situation. A drill is when staff carries out as many of the processes, procedures, and mitigations that would be performed during one of the emergencies as possible.
While drills are limited in scope, they can be very useful to test specific controls for gaps and possible improvements. A disaster recovery plan can be carried out to some length, backups can be tested with the restoration of files, and services can be failed over to secondary cluster members.
During a tabletop exercise there should be a moderator or facilitator who will deliver the scenario to be played out. This moderator can answer “what if” questions about the imaginary emergency, as well as lead discussion, pull in additional resources, and control the pace of the exercise. Inform the participants that it is perfectly acceptable to not have answers to questions during this exercise. The entire purpose of tabletops is to find the weaknesses in current processes to mitigate them prior to an actual incident.
A member of the exercise should also evaluate the overall performance of the exercise, as well as create an after-action report. This evaluator should take meticulous notes and follow along any runbook to ensure accuracy. While the evaluator will be the main notetaker, other groups and individuals may have specific knowledge and understanding of situations. In this case, having each member provide the evaluator with her own notes at the conclusion of the tabletop is a good step.
Participants make up the majority of this exercise. Included should be groups such as finance, HR, legal, security (both physical and information), management, marketing, and any other key department that may be required. Participants should be willing to engage in the conversation, challenge themselves and others politely, and work within the parameters of the exercise.
What to include in the tabletop:
Current runbook of how security situations are handled.
Any policy and procedure manuals.
List of tools and external services.
Post-exercise actions and questions:
What went well?
Are any services or processes missing that would have improved resolution time or accuracy?
Are any steps unneeded or irrelevant?
Identify and document issues for corrective action.
Change the plan appropriately for next time.
The Federal Emergency Management Agency (FEMA) has a collection of scenarios, presentations, and tabletops that can be used as templates.
Encourage staff to either set up a home lab or provide a lab for them. Labs can be used for testing out real-world scenarios, as well as practicing skills and learning new ones. Labs can be created at a relatively low cost by buying secondhand equipment. The best way to learn for the majority of people is hands-on, and with a lab there is no risk introduced into a production environment.
Compete in or create Capture the Flag competitions (CTFs). CTFs are challenging, and they can provide cross training and team building, as well as increase communication skills. Most information security conferences have CTFs. If you are looking to expand a team, CTFs are a wonderful place to find new talent. Not only will participants be showing their level of knowledge, but also communication skills, how well they work with others in a team, and their willingness to help and teach others.
Find or create a project. Automate something in the enterprise, find a need and fill it. It doesn’t matter what the skillset, there will be a project out there that needs help. Documentation is needed on 99% or more of the open source projects out there.
Attend, organize, volunteer, speak, sponsor, or train at an industry conference or local meetup. There are hundreds of them across the US and they almost always need volunteers. Just attending a conference has its benefits, but truly immersing yourself will push you further to learn and experience more. Many careers have been started by having a simple conversation about a passion over lunch or a beer. Networking is a game changer in our industry, but it’s not the silver bullet for everyone. You can network all you want, but unless you are a desirable candidate it won’t matter. Having a willingness and desire to learn, listen, collaborate, and the ability to think for yourself are all ideal traits in such a fast-paced industry.
Creating an information security program is no easy task. Many programs are broken or nonexistent, adding to the overall lack of security in the enterprise environment today. Use this book as a guide to work through the different areas and to suit them to a custom-tailored plan. Organizational skills, a good knowledgeable, hard-working team, strong leadership, and an understanding of the specific environment will all be crucial to an effective program.