Effective Tabletop Exercise Design

I used to hold the position that when an organization decides to execute a table top exercise it was because they were mature to the point of having an incident response plan. The organization utilizes the table top to test the execution IRP and identify any gaps. I mostly thought the exercise was to affirm that the controls and processes in place were adequate.

I was mistaken.

Often the exercise is meant to shine a spotlight on how unprepared a company is if an incident were to occur. A tabletop exercise could be to demonstrate to management that in the event of a breach they don't know who is responsible for what, what the proper response should be, when to involve legal council, when to involve law enforcement, etc.

Table top exercises are an effective tool for measuring an organization's capability of responding to an incident throughout all maturity levels.

This point highlights the importance of having a clearly defined objective before heading into a tabletop exercise.  Objectives should align with past, current, and future capabilities. The objectives enable tabletop planners to design the scenario to be inclusive of all stakeholders and test the cohesiveness of supports systems in response to potential cyber attacks.

The next step should be to develop the team who will design the exercise. This could be an outsourced resource who can objectively review policies and procedures and design an exercise based on provided documentation. The design team could also be internal resources familiar with the processes in-house. The objectives should drive defining the personnel required to design scenarios. The designers should not be a part of the exercise itself. The designers should also be unencumbered from pressures of the results of the exercise (political or otherwise). The design team should be allocated anywhere between 1 to 3 months to adequately plan the exercise.

The design team will flush out all the participants in the exercise. It is key for a table top team to understand the audience of the exercise. It has to tailor its language to be inclusive. The exercise must also speak to the environment of the organization. Specific tools they use, understanding of security concepts, native acronyms, are among the things that may need to be accounted for when designing the exercise. The participants should all be able to understand and track the scenario as it is executed during the exercise.

In order to build an effective table top exercise the design team must account for these common issues with table top execution:

• Cyber scenario objectives not clearly defined. 
• Rules of engagement not clearly defined.
• Reduced awareness due to Senior leaders not involved in planning.
• Cyber injects are not executed as planned. 
• Training audience fights against scenario
• Account for logistical/technical issues during execution

Now that your team is built, the objectives defined, and the audience identified, the designers will be able to begin building the scenario. Designers must build realistic events that could occur that impacts the organization, partners, and stakeholders. The scenario will be closely tied to the objectives of the exercise. The scenario is comprised of scripted events that are meant to facilitate discussions between the different groups involved in the exercise. The scripts should allow for improvisation so simple modifications and injects (new data for participants to consider) are available. 

Now all that's left is the execution and after action reports. It is necessary to have someone whose only function is to take a copious amount of notes to build the report. Candor is a necessity of any table top exercise. It is meant to identify any gaps in the organization and help develop plans to rectify any findings. It must be communicated that the outcome of the exercise is meant to make all parties involved better. The event is not meant to shame but to uplift by informing and building.

Defending the top 5 ways attackers own your network

Recently the Cyber security firm Praetorian published a report that details the top 5 attack methods used by the firm over 100 separate penetration test engagements. The report was based on what are the tools and techniques used by attackers once they already have a foothold within the network. This premise is based on the fact that it is near impossible to insure that all employees will not click on a bad link emailed to them that may run code or steal their credentials. The report show the most common ways they went from getting that user to click a bad link to owning the entire network.

The top 5 methods in order were:

• Weak Domain User Passwords 
• Broadcast Name Resolution Poisoning (aka WPAD) 
• Local Administrator Attacks (aka Pass the Hash) 
• Cleartext Passwords Stored in Memory (aka Mimikatz) 
• Insufficient Network Access Controls

You'll quickly notice that 4 out of the 5  deal credentials.  0 out of 5 of these methods even deal with patch levels.  And 5 out of 5 of these methods are not the sexy zero day in which you have no defense. The common misconception is that attackers use methods that are cutting edge to take control of a network. In actuality and practice attackers use commonly used methodologies and tools to exploit systems. Additionally the top 5 security holes Praetorian identified have been known for many years now. 

So the bad news is that these security holes have been around for years. The good news is that these security holes have been around for years. This is good news because the ways to mitigate these issues are readily available and do not require the acquisition of some additional software or security appliance.

Weak Domain User Passwords

A lot of organizations feel safe because they have followed what has become common place in thinking what a secure password is.  "Well my domain is set to require 8 characters, 1 special character, 1 capital letter, and 1 number as a password." Sadly, this does not make for a secure complex password. In order to satisfy these requirements users will commonly use passwords like P@ssword123 and Winter!2016.  I don't believe that anyone would consider either of these examples of secure passwords. Organizations need move away from passwords towards passphrases.  Where Winter!2016 is considered weak !LoveTheWinter!0f2016 is orders of magnitude more difficult to crack simply because of the increased number of characters used.  Passphrases are easy to remember and provide enough security to thwart most attempts to crack.

Additional guidance is that when possible two factor authentication should be implemented especially for administrative and remote access.  An organization with less strict password rules has a dramatic net positive impact when complimented with a second factor of authentication. 

Broadcast Name Resolution Poisoning

Broadcast Name Resolution Poisoning attacks leverage how systems attempt to find other systems on the network to steal credentials.  If a system looks for a system that is neither set in the local hosts file or in DNS looks to NetBIOS/LLMNR for answers. NetBIOS/LLMNR broadcasts traffic across the network to search for a system. Because this is broadcast traffic all systems see it and all systems can respond. An attacker can leverage this function to gather credentials that can either be cracked offline or replayed to other systems to increase network access. 

Most organizations have no business need for NetBIOS/LLMNR. The guidance is to disable this and populate the DNS servers with entries for the enterprise systems.  Web proxy auto discovery (WPAD) operates similarly to NetBIOS/LLMNR.  This function should also be disabled within web browsers.  An organization can also choose to forward WPAD traffic to an internal proxy that is controlled.

Pass the Hash

A lot of organizations do not know how to properly manage the local administrator password on the many client systems across a network. Often they have the same username and password across each of the systems because that makes for ease of administration. Unfortunately, if an attacker gains access to one system and is able to compromise the password hash they are then able to have administrative access to all systems that use that account without the need for cracking the hash.

To mitigate the exposure to pass the hash attacks, organizations should look to apply a defense in depth type approach. First is to restrict the ability Domain and Enterprise administrators to login workstations.  This way the credentials will never be on the system to be stolen. Another technique is to remove the ability of workstations to initiate inbound connections to other workstations. In general there should be no reason for client to client communications to occur. Only trusted administrative network segments should be allowed to login remotely. Later versions of windows allow you to remove the ability of storing credentials in local databases.

Microsoft also has released the Local Administrator Password Solution (LAPS) that generates a random password for each local administrator account. That password is then stored in Active Directory with the computer object. Domain administrators can then grant permissions to certain users to read the password to perform administrative functions.

Clear text passwords stored in memory

Mimikatz is a popular attack tool used to steal cleartext passwords from the LSASS process in windows.  If an attacker is able to obtain administrative or system level privileges, usernames and passwords can be pulled directly from memory.

Later versions of windows have resolved this issue by default but older versions must have been patched with KB 2871997 and have modified the registry to set HKLM\SYSTEM\CurrentControlSet\Control SecuityProviders\Wdigest UseLogonCredential REG_DWORD to 0. This should be considered a high value registry key so it should be monitored to make sure it hasn't been changed.

Insufficient Network Access Controls

This attack vector was touched on in the pass the hash mitigation strategy. Attackers often have free reign on a network once they get a foothold. They are able to touch other client systems as well as all of the critical systems due to a lack of network access controls that segregate systems. The network should be restricted in such a way that systems should only be able to talk to each other if there is a business need to do so. 

Organizations often grasp the concept of having a DMZ and segmenting their network into trusted zones in regards to untrusted traffic coming in from the outside.  The same logic should be applied internally. Client systems should be barely trusted because while administrators do have some control of the system, the end user may have engaged in some bad behavior that lead to the compromise of the system that has yet to be detected. The defender must think in terms of limiting the damage that system can do as much as possible while not significantly impeding the end user from completing daily tasks.
  
To accomplish this network administrators must work with business units to identify what are critical systems and understand what personnel should and should not have access to.

Reference:

Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft

How to Dramatically Improve Corporate IT Security without Spending Millions

A world class SOC for any organization.

Carson Zimmerman has worked out what has become close to gospel in my approach to the design and implementation of an effective Security Operations Center.  He outlines 10 strategies organizations should take to implement a SOC that demonstrate maximum effectiveness and reflect the characteristics of a world class security operations center.  The 10 strategies are:

Strategy 1: Consolidate Computer Network Defense Under One Organization 
Strategy 2: Achieve Balance Between Size and Agility
Strategy 3: Give the Security Operations Center the Authority to Do Its Job . 
Strategy 4: Do a Few Things Well 
Strategy 5: Favor Staff Quality over Quantity 
Strategy 6: Maximize the Value of Technology Purchases 
Strategy 7: Exercise Discrimination in the Data You Gather
Strategy 8: Protect the Security Operations Center Mission 
Strategy 9: Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence
Strategy 10: Stop. Think. Respond . . . Calmly 

If there is any theme to my aphorisms it's that organizational goals should be plainly defined and understood before any technology purchases or acquisition of many staff members/contractors.  Zimmerman outlines 5 strategies before mentioning the technologies used in a SOC. He makes it clear that the organization primarily must have bought in and defined a clear mission in order to be successful. Also it highlights that a SOC that operates at a high level does not necessarily need to be reserved exclusively for large organizations with matching budgets.  


Strategy 1: Consolidate Computer Network Defense Under One Organization 

Strategy 1 is in the appropriate place because quite often the struggles of the SOC occur because its capabilities are fractured within the organizations. Engineering occurs in a group that is not specific to the SOC.  Tier 2 is often commingled with operations tier 2 who will have issues escalating incidents to the correct personnel. An example is Firewall tickets end up going to the SOC when it should go to network operations. In a perfect world the SOC has its own triage, Tier 2, engineering, administration, and analysis teams. In typical deployments I suggest that triage infrastructure be maintained and personnel trained on which incidents belong in which buckets. However it is imperative that the remaining functions be reserved exclusively for SOC specific activities. Internal processes, availability of resources, and effective support of the SOC mission are measurably improved with independence from other organization activities.

Strategy 2: Achieve Balance Between Size and Agility

Strategy 2 is meant to address the need for the SOC to be structured in a manner that best fits the organizational need.  It needs to be sized appropriately so that it is able to effectively meet the demands that may be placed on it while having the ability to dynamically adjust to fluctuations in the environment and/or scenario. In this strategy, Zimmerman provides guidelines for the appropriate sizing and structure of a SOC depending on the organization size and footprint.

Strategy 3: Give the Security Operations Center the Authority to Do Its Job . 

Strategy 3 should've been number 1 to me.  Once the idea of a SOC has been signed off on, the first thing that should occur is the drafting of a charter and mission statement. Management should sign off on the documents granting them the appropriate authority to monitor systems, detect and resolve incidents throughout the enterprise, and execute its mission. The organizational structure should  appropriate autonomy from other potential competing interests. Zimmerman provides suggestions to where the SOC functions should reside in an org chart. The recommendation I often make is that the SOC should be tightly coupled with the Network Operations Center (NOC) while independent. This has the benefit of supporting each other's activities while fostering a collaborative relationship.

Strategy 4: Do a Few Things Well 

When writing the charter and mission statements, special care must be taken in defining the SOC capabilities. This will go a long way in managing expectations and budget. It will also provide focus in making sure you are able to deliver services effectively. These can be compliance driven or shaped by need to provide specific functions (vulnerability scans, application assessment, tool implementation, etc). While deciding on your capabilities, it is equally important to define metrics that are able to effectively show how well you are doing at providing the services. It is also useful to have an eye for the future on what services are on the horizon that could complement the current offerings as the SOC matures.

Strategy 5: Favor Staff Quality over Quantity 

This strategy is all about the acquisition and retention of information security talent. There is much to be said about the talent gap in security. The need for information security professionals is far outpacing the number of individuals with the skill set to fill that need. Zimmerman states that your focus in staffing the SOC should be on acquiring the staff that is able to think creatively and outside of the box to solve problems. These types of individuals may be worth several people in that they find automated ways to sift through data to identify problems and solutions where others may toil for more time to arrive at the same solution. I tend to recommend that organizations look inside of their own organizations first to fill the talent gap. Information security is a hot field that people from all types of backgrounds are looking to get into. The problem is that it is often a field that is often difficult to break into and people do not know the steps they need to get into the arena. Organizations need to start enabling their people and searching for folks outside of the normal realms to find talent. What is often all that is necessary for good security professionals is enthusiasm. Feed that enthusiasm with opportunity. Having this mindset has the dual effect of learning to leverage the talent you have and nurturing it to grow into something bigger and better. It provides a positive work environment and bolsters retention.

Strategy 6: Maximize the Value of Technology Purchases 

We've gone through people, processes, and goals before addressing the technology. This is very intentional. It helps you establish all the things you want out of your SOC before even thinking about the technology that can deliver these objectives. Many organizations make the mistake of shaping their organizational goals and processes around technology when it should be the polar opposite. By setting your goals around the needs of the constituents you are able to develop requirements that are unique to your organization. From there you are able to evaluate vendors against the specific needs you have defined. These needs may end up being filled with simple solutions or multiple complex technologies that have to interact with each other to secure your systems.

One thing that I harp on is that you cannot have a security program or solution at any level of maturity without having a full mapping of your systems and their expected behaviors. At the onset of Strategy 6, Zimmerman brings up that before you can operationalize your SOC, they must be provided with a database of system assets and a method to keep it updated. This database will heavily impact your technology choices and how/where they should be deployed.

Strategy 7: Exercise Discrimination in the Data You Gather

Strategy 7 goes hand in hand with Strategy 4. If you know what you do well then you should know what information you need to do it well. You can't do anything well if you are inundated with extraneous information. The SOC needs to be discriminate in the information it receives and processes. This allows for the freeing of resources to effectively perform its duties.

Zimmerman then goes on to provide the reader with best practices of where to obtain data and how to centralize your log processing out of band.

Strategy 8: Protect the Security Operations Center Mission 

This strategy folds into Strategies 1 and 3. Whoever is running the SOC must be cognizant of its mission and prevent it from being pulled into conducting tasks that do not support that mission. Organizations tend to tap the SOC for operational or development needs due to the tendency of SOC personnel having skill sets that complement these arenas. Zimmerman's description of this strategy is that the SOC must have its own infrastructure, people, processes, and budget.

Strategy 9: Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence

Cyber Threat Intelligence Feeds are a controversial topic in information security. Threat Intelligence is the process of examining an Advance Persistent Threat (APT) actor's activities and creating a fingerprint to help identify them. Criticism of Threat Intelligence feeds is that an APT's methods are typically unique to the organization they are trying to exploit. Therefore the fingerprint that is associated with one attack should not match a separate attack.  So the effectiveness of threat intelligence feeds have been called into question.

I believe that a mature SOC is able to leverage these feeds in a way that help them identify a similar attack more quickly than they would without the information provided to them in a feed. Cyber Threat Intelligence feeds are not meant to be a magic bullet to help organizations in similar industries quickly detect a persistent threat actor. They are meant to share information to the community so everyone is better able to detect and thwart concerted efforts to undermine your security posture.

Zimmerman goes through the steps of how an organization can establish a Threat Intelligence operation that is internal to your organization. With an internal Threat Team, analyst will not have to ingest and process the contents to understand if it is relevant for their environment. The threat data is an analysis of external and internal data to develop signatures to automatically detect an ongoing attack. Cyber Threat Intelligence teams conduct malware analysis, digital forensics, and in depth network traffic analysis to observe how they have been compromised. This information is then feed back to the SOC team so they are able to detect similar threats in the future.

This is not for the faint of heart and is reserved for the most mature of information security programs.

Strategy 10: Stop. Think. Respond . . . Calmly 

If you have taken care in previous strategies, the tenth should come relatively naturally. In the event of an incident, personnel should have been trained to follow their playbooks to detect, respond, and remediate. The correct communications have occurred, the correct actions to quarantine have taken place, correct methods to preserve evidence have been followed, and any after action lessons learned have been recorded. The best way to achieve the calm, measured response throughout the organization in the event of a compromise is to practice during seemingly tranquil times. This will indoctrinate the staff on what they should be doing when and also hammer out any inadequacies in the current processes.

If any organization is looking to build out SOC I would recommend they reference Zimmerman's Mitre paper as a place to begin. It gives all the details one would need in a successful SOC covering things like logistics, technology deployment strategies, staffing, and creating a mission to build from.

Zimmerman, Carson. 2014. Ten Strategies of a World-Class Cybersecurity Operations Center
https://www.mitre.org/publications/all/ten-strategies-of-a-world-class-cybersecurity-operations-center

A primer on HTTP Security Headers

 

Implementation of HTTP security headers can be a complex and confusing topic.  There are several headers that are counter-intuitive and can lead to a compromise in your security posture and have unintended consequences.  Below is a list of HTTP security headers, a brief explanation of their function, and security options. 

Content Security Policy

Content Security Policy (CSP) is a control implemented that only allows browsers to load content explicitly specified by the operator of the website. This control was put in place as a means to mitigate Cross-site scripting and other attacks via code injected by an attacker. Most browsers either fully or partially support CSP.  CSP can be either implemented in block or report mode. Report is a good setting for testing to insure that the implementation is functioning as expected across browsers. Earlier implementations of CSP were the X-Content-Security-Policy and X-Webkit-CSP.  These implementations should no longer be used as they have been deprecated and have had numerous issues.   

There are several configuration options known as directives for CSP. These options can be configured via a setting in your choice of web software (nginx, apache, IIS) or via Meta tags in your HTML code. The following is a list of available options:

• default-src : "special directive that source directives will fall back to if they aren’t configured." In general this setting should always be set to insure that the default behavior of allowing all resources isn't allowed.  A default-src gotcha is that not all directives inherit from default-src.  Base-uri, form-action, frame-ancestors, plugin-types, report-uri, and sandbox all need to be explicitly set or will use the browser's default setting. A default-src setting of "self" is generally safe but a more locked down approach would be to set it to "none" and then explicitly state resources you want allowed.  

• script-src : sets which scripts the site will execute. This setting has two additional options of unsafe-inline and unsafe-eval which are labelled such because they are potentially dangerous and could expose the site to XSS attempts.  Implementation of the unsafe-inline option will allow for <script>, javascript:, URLs, inline event and inline <style> elements.  Implementation of the unsafe-eval option will allow for the site to execute dynamic code options.  
• object-src : Define from where the site can load plugins.  It specifies valid sources for the <object>, <embed>, and <applet> elements. In instances where the site tries to fetch a resource outside of the bounds of what's defined in object-src, an empty HTTP 400 response code is returned.  
• style-src : Define where CSS styles can be loaded from. This includes both externally-loaded stylesheets and inline use of the <style> element and HTML style attribute.  It is important to note that style-src has no impact on Extensible Stylesheet Language Transformations (XSLT).  XSLT is covered by script-src directive.  
• img-src : Define from where the site can load images
• media-src : Define from where the site can load video and/or audio,
• frame-src : Define from where the site can embed elements like <frame> and <iframe>
• font-src : Define from where the site can load fonts,
• connect-src : Define from which sources the site can load content using the Fetch (provides an interface for fetching resources locally and across the network), XMLHttpRequest (provides client functionality for transferring data between a client and a server), WebSocket (for creating and managing a WebSocket connection to a server), and EventSource (used to receive server-sent events) Connections
• form-action : Define valid sources that can be used as the action of HTML form elements,
• sandbox: applies restrictions site actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy
• script-nonce : Define script execution by requiring the presence of the specified nonce on script elements,
• plugin-types: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
• reflected-xss: instructs a browser to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
• report-uri: instructs the browser to report attempts to violate the Content Security Policy

 

X-XSS-Protection

This header is a feature that is supported by Internet Explorer and Chrome browsers.  If malicious input is detected the browser will either remove the script or stop the page from being rendered at all according to how the header is set.  Below are the valid protection settings offered by the header:  

• 0 - Disables the XSS Protections offered by the browser
• 1 - Enables the XSS Protections
• 1; mode=block - Enables XSS protections and instructs the browser to block the response in the event that script has been inserted from user input, instead of sanitizing.
• 1; report=http://site.com/report - A Chrome and WebKit only directive that tells the browser to report potential XSS attacks to a single URL. Data will be POST'd to the report URL in JSON format.

By default X-XSS-Protection headers are set to 1.  This may be the least secure option there is counter-intuitively.  An X-XSS-Protection setting of 1 can actually inject new vulnerabilities into your website and has many examples of being bypassed. When implementing this security header the safer options are 1; mode=block and 0.  

HTTP Strict Transport Security (HSTS)

 HSTS is a security option that instructs the browser that it is only to interact with the website via the secure transport protocol (HTTPS).  It prevents attacks that will tell the browser to communicate over clear channels when it should be encrypted. HSTS is implemented by sending the Strict-Transport-Security header over an HTTPS connection.  The browser will ignore any HSTS options sent via HTTP.  The server sends the Strict-Transport-Security option with a max-age value that instructs the browser to send all future requests via HTTPS over the assigned time period. 

HSTS automatically turns insecure links referencing the web page to secure links and instructs browsers to refuse creating a connection if the SSL certificate has an error that could question the legitimacy of the secure connection (certificate expiration, mismatched names, etc).  

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The above example sets the max age to one year, applies HSTS to the domain and subdomains (example.com and mail.example.com), and tells the browser to use a preloaded list of domain names to insure secure connections are created prior to the browser even initiating a connection.  

  

X-Frame-Options

The X-Frame-Options header is used to indicate if a browser should use a <frame>, <iframe> or <object> to build webpages.  This header is meant to be a mitigation for clickjacking attacks that trick users into clicking something that is different than what was expected.  X-Frame-Options prevent content from being embedded into other sites. The available values for X-Frame-Options are:

• DENY: The Page cannot be displayed in a frame
• SAMEORIGIN: The page can only be displayed in a page from the same origin as the page itself.  An origin is defined as a combination of URI, hostname, and port number
• ALLOW-FROM:  The page can only be displayed in a frame in the specified URL.  This option is only supported by Internet Explorer and Firefox as Chrome and Safari provide this functionality via Content Security Policies.  

HTTP Public Key Pinning (HPKP)

 Currently supported by Firefox and Chrome, Public Key Pins allow for hashed public key information to be stored in a browser's cache.  There are hundreds of Certificate Authorities (CA) that are capable of providing certificates for websites.  While unlikely it is possible for an attacker to trick a CA into issuing a certificate to a fraudulent entity.   With certificate pinning, website administrators are able to instruct browsers to only trust certain CAs. Below is an example implementation of HPKP:

• Public-Key-Pins: max-age=2592000

                  pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";

                  pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";

                  includeSubdomains;

                  report-uri="http://example.com/pkp-report"

Max-age specifies the amount of time in seconds the browser will enforce public key pins.  Public Key pins require that a primary and backup key be issued.  The backup key is in case the current key need to be replaced.  They key and backup keys should be created from two independent Certificate Authorities.  Above are 2 base64 encoded SHA 256 hashes of the certificates to be passed to the browsers.  IncludeSubdomain applies the HPKP to any of the subdomains of the site.  Report-uri is used to send any validation failures to specified URI for reporting. Reports are sent in addition to terminating the connection on any detected failures.  

HPKP implementation is rare throughout the internet.  It's usage has been limited because it can be dangerous to implement.  If keys are not managed carefully, it is possible that the website will be rendered unavailable for the duration of the max-age interval. 

X-Content-Type-Options

MIME sniffing allows browsers to guess the file type being presented to it by the server by reading bits of it. This is done when file types are not explicitly defined by the web server.  An attacker can abuse this behavior by tricking the browser into misinterpreting a file type and downloading malicious content.  The X-Content-Type-Options HTTP header allows you to tell the browser that is should not try to guess the file type and only use those that have been defined.  This header is only currently supported by Chrome, Safari and Internet Explorer.  Below is the implementation:

• X-Content-Type-Options: nosniff

Cross Origin Resource Sharing (CORS)

It allows a website to utilize the resources that are hosted on domains other than itself. Websites often load resources like CSS stylesheets, images and scripts from separate domains. CORS allows for explicit definition of the sites, methods, credentials, and headers allowed across the resources.  Implementation of CORS should be as restrictive as possible only allowing necessary domains and methods to operate the site.  Below are the list of headers implemented by CORS:

• Access-Control-Allow-Origin: a single url/domain, wildcard (*), or null are the only accepted values.  Wildcard allows any domain while null allows no domain.  
• Access-Control-Allow-Credentials: allows cookies or other credentials to be passed in cross origin requests when set to true.  
• Access-Control-Expose-Headers: indicates which headers are safe to expose.  Example values are X-Custom-Header, content-length, etc
• Access-Control-Max-Age: header indicates how long the response can be cached
• Access-Control-Allow-Methods: indicates which HTTP methods can be used when making a request. ie: Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD
• Access-Control-Allow-Headers: indicates which headers that can  be used when making a request. ie: Access-Control-Allow-Headers: Origin, Content-Type, Accept
• Access-Control-Request-Method: indicates which method will be used when making a request.  ie: Access-Control-Request-Method: GET, PUT, POST, DELETE
• Access-Control-Request-Headers: indicates which headers that will  be used when making a request. ie: Access-Control-Request-Headers: Origin, Content-Type, Accept

 Additional Reading

X-XSS Protection

http://blog.innerht.ml/the-misunderstood-x-xss-protection/

Public Key Pinning

https://tools.ietf.org/html/rfc7469#section-2.1.3

Cross Origin Resource Sharing

https://www.w3.org/TR/cors/#access-control-request-method-request-header

X-Content-Type-Options

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

HSTS

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

Content Security Policy

https://content-security-policy.com/

Measuring Your INFOSEC

Metrics are reflective of a mature information security program. When you have policies and processes in place and you are actually measuring their effectiveness then you are able to make objective decisions about what you can do to improve the effectiveness of the program. If a senior member of the organization asks how secure are we, would you have an answer?  What if the question were am I more secure today than I was yesterday?  How do I know if I'm spending money on securely effectively?  What's my security posture relative to my peers?  These are all questions that cannot be answered within policies and procedures alone. In instances where an information security program must take corrective action, it will often be met with resistance from detractors. In order to make a substantive argument in your favor, you need objective numbers that speak in a way that is understood throughout the organization.

Effective Metrics Tell A Story 

From that story the organization should be able to derive a lesson that born from conclusions that were found in analysis of the data. Good metrics demand a story. The story reveals a lesson. learning from the conclusions drawn by analysis of the data. Like any good story, you have to know your audience and select your theme to connect with their frame of reference." Metrics should be able to fit into one of three categories that support different levels of organization decision making:

• Strategic:  speak to overarching corporate objectives
• Managerial: speak to initiatives that are in place to meet the corporate objectives 
• Operational: low level details that speak to the day-to-day activities of the corporation

The characteristics of a good metric in information security are:

• Predictive: provides the ability to forecast security outcomes with a high correlation between the metric and the outcome. This type of metric allows the organization to look reliably into the future based on historical trends. These metrics can be used to stall, limit, or prevent incidents before the occur.  
• Relevant: focused on the specific needs of the organization and provide actionable data that steers direction of information security.  The options for metrics are boundless so the selected metrics must mean something that will enhance knowledge.  
• Actionable: provides the organization metrics that the organization has the ability to influence.  An effective metric is not one that the organization is powerless to do anything about to exercise some control.  
• Accurate: metrics may or may not need pinpoint precision to be effective.  This characteristic is dependent on the requirements of it by its recipients.  However, the level of accuracy needs to be reflected in its repeatability.  
• Independent: reflect the metric's ability to be resistant to manipulation by outside forces.  Shows the trustworthiness and integrity of the metric.
• Tangible: metrics should be quantitative.  Ratings such as high, medium, and low should not be used to convey any information in security metrics.  The metrics should fall into either a state or rate.  You can measure the current position of something or the direction/rate of change of something.  
• Repeatable: metrics should be easily gathered and updated via automated means as much as possible.  This allows the collection to have the same impact and accuracy throughout the history of the metric's collection.
• Cost: the cost of the metric does not necessarily mean that the metric needs to be cheap.  But it's value does need to outweigh the cost.  Most metrics are cheap to collect but in instances where a survey may need to be conducted and analyzed there may be a heavier cost to bear.  

Sample Metrics

Finding meaningful metrics for your organization are really dependent on your unique organizational needs and objectives.  However there are a number of metrics out there that are good for a base example.  When selecting metrics define the metric name, metric description, metric purpose/objective, required data sources, frequency of measurement, units of measure, and benchmark or goal. Below are some sample metrics to consider.

Time taken to Remediate Security Events

The amount of time between the detection of a security incident/event  and when it has been marked as closed/remediated.  This metric shows how efficient your security operation center may be operating.  This could be considered a management and operational metric.

Mean Time to Detection

The amount of time between the actual security incident and when it was detected/reported.  This metric shows how effective your detection and reporting mechanisms are.  This would be considered a management and operational metric.

Number of high/medium/low risks unresolved

The number of risks identified in the organization that remain unaddressed.  This metric measures the overall effectiveness of the risk management program.  This metric covers strategic, management, and operational.

Percentage of assets in risk management program

A useful metric as you are rolling out your program the tracks its progression.  This would be considered a strategic and management metric.

Patch Latency

Tracks the amount of time that has passed between the availability of a patch and it's implementation. The larger the amount of time that has elapsed the more susceptible the environment may be to attack. Patch latency measures the effectiveness of a patch management program. This would fall into the management and operational category.

Percentage of Change Authorizations

Measures the effectiveness of the change management program. A metric that insures that personnel are following the change management process that has been defined.  This could be an expensive metric to track as it may be difficult to discover qualifying changes throughout the asset inventory.  This would fall into the management and operational category.

Percentage  of Employees Who Have Completed Security Training

Measures the coverage of your security training program.  This would fall into management and operational metrics.

Percentage of Systems That Have Been Validated for Compliance

When an organization is undergoing compliance efforts (PCI/SOX/HIPAA) this is a metric that tracks its progression.  This metric could have financial implications as well as operational.  This would fall into strategic, management, and operational metrics.

Implementation of a measurement program can be a daunting task. In order to make sure that you are measuring pertinent information and that it continues to be worthwhile, you should take a systems approach to implementation.  State the requirements, have organizational backing, design and develop the measurement system and the metrics themselves, test the collection and dissemination mechanisms, execute the system, and monitor its effectiveness. A measurement program will arm a security manager with meaningful data that facilitates decision making that's not based in FUD (fear, uncertainty, doubt).

Buiding an Enterprise Risk Management Program

In this post, I outlined some high level steps to begin an Enterprise Information Security Program.  Once you have established policies and implemented the basic steps of an Information Security program, the next phase is to develop its capabilities and further align the effort with business objectives. The sign of a mature Information Security program is the integration of Risk Management. Where policies are the essential foundation of the program, risk management is the rudder that steers the ship. Policies, procedures, guidelines, and baselines provide the building blocks of the security program's direction where implementation of Risk Management identifies the impact to the organization if security controls fail.  

First let's define risk. It is common in the information security community to interchange the words risk and threat. These are in fact two different things.  An example is that you buy a lock for your door to prevent the threat of someone just walking into your home. While the risk of someone walking into your home is much lower in remote areas verse urban areas due to differences in population density. So people are often more likely to leave their doors unlocked in remote areas because while the threats are the same, the likelihood of occurrence is much lower. A more formal definition of risk is the "probable frequency and probable magnitude of future loss of confidentiality, integrity, availability, or accountability."

So while building your security program you've identified all of your information resources and established patch and vulnerability management policies. Upon your initial scans you've discovered 230 vulnerabilities and 125 missing patches. With your limited resources how do you decide what to patch first? What do you do if a critical vulnerability is discovered on a system that cannot be patched for business reasons? How do you decide if an expensive security control should be implemented? These are the kinds of questions a developed risk management program can answer by providing measurable business context.  

As with building a security program in general, the number one advice I can offer is to start small. Out of the gate do not try to building complex qualitative risk models that will bogged down in a quagmire of mathematical models that your organization most likely does not have the necessary historical data to build in the first place. Do not try to apply a risk category to every single component of your information system environment on day one.  Refrain from attempting to identify every single risk scenario before you've identified all of the critical risks. Do not attempt to achieve a "perfect" environment early on. Quick demonstrable wins and early successes will lead to a Risk Management program that has real, positive impact.  

One of the initial tasks in building an Information security program was to build an inventory of information assets. This is a key step in establishing a Risk Management Program as well. Risk Management requires an extra degree of detail in order to establish an accurate risk profile. Risk management requires knowledge that includes regulatory compliance details, housing of any personally identifiable information, credit card processing, etc. The process of discovering all of these types of details is known as risk profiling. This information can be gathered via interviewing or having the resource owner complete a questionnaire. The resource owners provide the details but the risk manager is assigned the task of assigning the overall sensitivity of the resource.  

The answers are fed into a predefined sensitivity scale that will assign low-medium-high sensitivity ratings. The risk sensitivity scales provide context so that risk evaluators are able to readily understand what makes one resource more sensitive than another. An official scale provides a universal metric across the enterprise that everyone understands is the standard.  

Your questionnaires have been completed and you have defined what it means to have a sensitivity of low, medium, and high.  Now you can begin creating a security profile of your information system resources.  Here is where to apply the approach of making these initial stages as easy as possible.  Start by profiling large chunks of the environment and then gradually increasing focus. If your environment consists of multiple datacenters, provide a profile by datacenter. If you outsource aspects of your information system, profile that environment vs what is locally managed. Provide a profile of a DMZ compared to internal environment. Whatever makes sense for your environment, create chunks of resources to provide a sensitivity rating to and gradually narrow your focus.  

Now that you've got your security profiles and have defined your most critical/sensitive assets, you can begin to leverage your vulnerability management processes that were put in place when building your security program. The vulnerability management  process will assign a weight to each vulnerability that is based on each assets sensitivity. Optimally your policy will outline things like the amount of time to remediate vulnerabilities based on sensitivity, processes to accept risks in instances they cannot be fixed, and processes to validate vulnerability fixes.  

An effective risk management program permeates throughout the organization. Risk liaisons are placed in each department to evaluate if their initiatives have adverse impacts to the overall risk of the organization. Risks are mapped to business objectives. Information security is represented at the enterprise risk committee in reporting to senior management risks to be prioritized along with other organizational risk. Having the  risk program at the executive level enables the program to be aligned to business objectives providing focus in support of the mission. 

Building An Enterprise Information Security Program

In the modern day, it is difficult to turn on the news, pick up a paper, or mill about everyday life without being exposed to the details of the latest hack that has disclosed personal information, tarnished a reputation, or pilfered currency. The threat landscape has lead to organizations looking inward to assess their current state and realize that they may not have the means or processes to deal with a hacking incident. What do we do if we’re being hacked? What if we’re already hacked? How would we know? What would we do? Seeking the answers to these types of questions typically lead to the establishment of a security program that puts in place processes and procedures that guide organizations to make the right decisions in the face of active attackers.

But where to begin? It can be a long, arduous road from knowing you need answers to actually having answers. In order to be successful in the establishment of an enterprise security program, it is necessary to define clear goals. In order for goals to be effective they must have a clear definition and be assigned deadlines. Deadlines must be practical yet challenging so that the success of the program is obtainable and measurable. The goals of a security program should be unique to your organization and reflect challenges specific to you. The outlined goals should lend themselves to the creation of a mission statement that functions as the guiding light of the security program.

After the goals have been articulated, the next step is to obtain official buy in from executive management. Often the buy in is presented in the form of a charter or something similar. It is essential that formal recognition of the security program is granted so that they are effectively empowered to meet their goals. This empowerment optimally places the security program in a branch of an organizational tree that is independent of the rest.

So you’ve set your goals, the executive management has sung your praises…..now what? It is untenable to attempt to make broad, sweeping changes to the organization effectively. The best approach is to follow the philosophy of crawl, walk, run. As with most things, it is best to try to set yourself up for success with quick wins. Identify and attack some of the low-hanging fruit within the company. An effective security program cannot begin without a thorough understanding of the systems, software, and connections. A good place to begin is defining the system boundary by gathering a detailed inventory of systems, understanding their function, and gathering a high level understanding of the most sensitive systems. This process can be completed with a mix of technologies that scan your systems, and interviewing your constituents to understand what is important to them.

The interview process will serve to provide two functions. Not only do you gather more details about the environment, but it also provides an opportunity to enhance the relationship between the security team and the other organizational groups. Early on it is imperative to evangelize the initiative. The message to the organization should relay the mission and goals. The personnel should also understand that security is not something that is going to be happening to them. It is meant to enhance awareness and increase effectiveness (note: effectiveness may need to be redefined to mean something other than as fast as possible). While conducting evangelization you may find that some of your most staunch supporters and enablers reside within the user base. Leveraging them may prove to be your most valuable resource.

Now that you’ve identified systems and interconnections, gathered an understanding of organizational processes, and weighed the critical assets, policies and procedures can begin to be formulated. This is another area to seek quick wins. Seek to find policies that may already in place and just haven’t been formalized yet. You don’t want to introduce any drastic changes to the community culture right out of the gate. This sort of action will not endear you to the user base. A good place to look would be the Acceptable Use Policy or Account Management. Once you have achieved some easy wins, seek to define policies and procedures that are more mature and are integrated throughout the enterprise. Policies and procedures should be woven throughout the software development lifecycle, operations, desktop support, and physical security. This integration ensures that security is embedded throughout the organization’s culture.

Now you’ve entered the walk portion of the program. Enter automation. It is important to establish strong policy prior to automation because they will shape the requirements for the solutions you put in place. Automation generally encompasses solutions like patch management, vulnerability management, and configuration management. Entire textbooks have been written on each topic but I will touch on a couple of key points for each.

When you were crawling you gathered a comprehensive list of systems. Now that you’re ready to walk you’re able to gather the current patch level of each individual system throughout the enterprise. You should know what’s up to date and what’s lagging. You should be in a place where you should strive to make sure that everything is patched. You are able to prioritize what should be patched immediately and what could wait until a later date. While the goal is to make sure everything is patched all the time, the cold, stark reality is that this is not always possible. Systems that cannot be patched should be documented and tracked.

For vulnerability management the goal should be to find all of the vulnerabilities in the enterprise. This is obtainable but it requires different automated scan types. Authenticated, network, external and passive scanning are all tools that can be deployed to detect vulnerabilities throughout the enterprise. Once a vulnerability is detected the process to remediate as defined in your vulnerability management policy initiates. The vulnerability should be assigned a score based on its criticality. This score dictates the immediacy of remediation or acceptance of the risk.

An effective configuration management program is a sure sign of a mature security program. The road to establishing a streamlined configuration management process can be daunting as you are inundated with terms such as CMDB (configuration management database), configuration items, and artifacts. As with the security program in general, a proper configuration management program begins with starting small and scaling out with success. It can begin with small wins such as establishing change control for a firewall or creating a gold workstation image. Configuration management begins in the walk phase but extends well into the run phase of the security program. 

Once you’ve mastered walking, you are ready to run with the establishment of correlation engines, threat hunting, incident detection and response, and digital forensics. By utilizing continuous monitoring, you will be able to dynamically detect when bad things are happening in your environment, and launch processes that quarantine the attack and allow for further investigation limiting impact as much as possible. This phase has close ties with lawyers, insurance and law enforcement so that they are able to quickly act in the event of a breach. A security program that is running is able to measure how fast and efficiently it’s running and provide quantitative data points that gives feedback on how it can improve.

Whether you’re a team of one or a part of an organization that has substantial resources that can back a full fledged security program with specialized teams, the process of beginning an effective program begins with starting with small, visible wins that garner willing and enthusiastic participation throughout the organization.  Identify low-hanging fruit to be plucked to gain momentum and ride successes until you've met your goals for the program and progressed into a mature enterprise.