Articles

Complying with the PCI DSS Standards – Who do they apply to?

March 29, 2021 by Tony Perez Leave a Comment

Our previous article, Making sense of PCI DSS for online stores, introduces us to the 12 PCI DSS requirements and aligned them to their respective 6 objectives. While we focused predominantly on online stores, the PCI DSS standards apply to all businesses involved in the collection, storage and processing of credit card information, including the company selling the goods / services.

Whether its your favorite food truck vendor, automotive detailer or favorite online market place. PCI DSS standards do not discriminate, and “I don’t know” will not help post-compromise.

The Payment Processing World

Here is a high-level view of what payment ecosystems look like in the 21st century (source: business insider):

Every business that is part of the payment processing supply chain fits somewhere into the matrix, and must be familiar where their respective scope and responsibility as it pertains to PCI compliance.

The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process or transmit cardholder data or sensitive authentication data.”
PCI DSS v 3.2.1

Remember, PCI is wholly focused on protecting the entire payment card processing supply chain, and the business providing the service and good is a critical piece of that puzzle.

Your Organization Type Defines Your Responsibility

So you want to accept payment from customers, but what / who is involved in that process? More specifically, who does what?

The following table below provides a simplified explanation of four key organization types every business should be familiar with if they want to accept customer payments:

Category	Description
Merchant	A merchant is any type of business who sells goods or services. Credit cards are the most common payment method used for these transactions.
Payment Processor	Manages the credit card transaction process. Processors can authorize transaction and works on merchants getting paid on time by facilitate transfer of funds.
Acquirer	This is the financial institution that maintains a merchant’s account in order to accept credit cards. Sometimes the payment processor and the acquirer are the same.
Issuer	This is the cardholder’s bank, responsible for paying the acquirer for approved card transactions and collecting payment from cardholders. he issuer, also known as the account issuer, or issuing bank, is the bank or financial institution who offers the credit or debit card to the consumer. They underwrite the cardholder, set the credit limit, and issue the card agreements.

It’s important to differentiate between the four key categories of the payment supply chain so that you can understand where you organization fits. Knowing where your organization fits will help reduce the scope of responsibility for your organization.

The key to successfully complying with the PCI standards is to clearly define your scope, failure to do so can leave you extremely exposed. If you are a merchant, this means that as an organization you don’t want to overlap with any of the other key categories. You do this by deferring the risk associated with the collection, storage and processing of any card data.

You reduce scope by identifying where and how data with card holder information flows through your network and systems. In an ideal world you DO NOT want any card holder information to flow through your network and system. This ensures your scope is as minimal as possible. Ways to ensure you do this is by NOT collecting payment information via emails, phones, chats or any other communication medium like tickets and solely using the payment pages and API’s provided by your processors for all payment collections.

Regardless of the type of organization, PCI DSS applies to you if you accept credit card payments.

Tips to Help Consumers and Businesses Reduce Scope and Risk

Trying to make sense of some of this can be tough, to help we share a table of real-world examples that can be treated as triggers for both consumers and businesses alike.

Consumers can use them to asses their own risk (e.g., Do I want to share my data with this merchant?) and businesses can use them to understand how “scope” works with compliance.

Type	Description
Physical Payment Form	If an organization asks you to fill out a PDF with your credit card information, scan and return it, it’s highly unlikely they are not PCI compliant. As a consumer, be very careful using this method. As a business consider updating your processes so that you can use payment collection forms provided by your processor.
No HTTPS	HTTPS is synonymous with online websites these days, while it doesn’t secure the website, it does secure data in transit. If an organization is asking you for payment information via a form that does not have HTTPS they are not PCI compliant. This means they are not taking care of your data as it transfers from your browser to their servers. Businesses that choose to collect this data need to ensure it’s transferred securely, HTTPS facilitates this.
Requesting Card Information via Communication Mediums	In 9 out of 10 instances, an organization that is requesting credit card information via one of many communication mediums (e.g., email, chat, phone, text, slack) are not PCI compliant. Many organizations don’t realize that the minute they do this they immediately expand their scope and now introduce a requirement to document and implement controls to secure those platforms (that rarely happens). As a business, do everything you can to train your team not to leverage any medium outside of the payment pages to collect information. This includes phone calls and virtual terminals, the minute you collect information via a sales call, or support engagement, it immediately broadens the scope to the phone service and the machines collecting the data.

If you have any questions, feel free to let us know at sales@coldpath.net.

Making Sense of the PCI DSS Framework for Online Stores

March 16, 2021 by Tony Perez Leave a Comment

A recent Nilson Report shows that payment card fraud losses reached $28.65 billion worldwide in 2019, with the US topping the list of most fraud-prone countries. We’ve also seen explosive growth in card fraud activity throughout the coronavirus pandemic as businesses move toward reducing their physical footprint and ramp up their businesses online.

Despite this, only 30%, or less, of organizations are PCI compliant. Why is this? What makes the PCI DSS framework so elusive to online stores?

This article will work to demystify the framework, making it more consumable to a) understand it and b) leverage it as a way to establish an appropriate security program for your online store.

With six goals and 12 requirements at the heart of the framework, compliance with PCI DSS ensures protection to payment card data. It does this by establishing technical and operational requirements for all supporting systems, and personnel, responsible for processing, storing or transmitting any element of the cardholders data. Yes, this means all merchants, regardless of size have a compliance obligation.

Failure to align all elements associated with your payment card operations with the applicable PCI DSS controls increases the potential risk for malicious or accidental actions leading to a breach or loss of your customer’s payment card information (this includes sensitive data that is printed on a card, chip data, etc..).

The 6 Goals (Objectives)

We will begin by outlining PCI DSS’s central goals, objectives, before moving into an overview of the different requirements. We always start by looking at the objectives because they provide a blueprint of what the framework is trying achieve, and in the case of PCI DSS it provides an outline from which the requirements will be structured from.

It helps better digest the requirements as it groups them according to the desired end-state. This makes it consumable to organizations, and provides a a sensible framework that can be used to establish an organizational security program that extends well beyond the online store.

6 PCI DSS GOALS

Goal	Description
Build and Maintain a Secure Network	Establish and maintain a secure network and system in order to ensure that payment transactions are processed in a robustly secure network. To achieve this, firewalls must be established to protect cardholder data and these firewalls must be effective without causing inconvenience, such as slow processing times, to cardholders.
Protect Cardholder Data	Protection of stored cardholder data with the needed steps taken to secure against hacking including securely encrypting data that is transmitted through public networks.
Maintain a Vulnerability Management Program	Establishing a vulnerability management program which includes frequently updating anti-virus software, anti-spy software, and other anti-malware solutions in order to protect against malicious hackers.
Implement Strong Access Control Measures	Restrict and control access to system information and operations. Cardholder data should not be provided unless it is required to effectively carry out a transaction and each person who uses a computer in the system must be assigned a unique and confidential identification name or number. This includes protecting physical cardholder data as well as data submitted electronically.
Regularly Monitor and Test Networks	Constantly and consistently monitor and test to ensure that all security measures are in place and working effectively.
Maintain an Information Security Policy	Maintain a policy that addresses information security for all personnel.

The Requirements

You will notice in the table below that all requirements are aligned appropriately with their corresponding goal. This makes it especially clear to the organization why they are being asked to do something. The PCI SSC goes on to highlight the importance of incorporating these requirements into “business-as-usual” (BAU) activities as part of an organizations security program.

The reality is that for most online stores, this is most probably the only security program that exists within the organization. The good news is the same objectives, and some of the corresponding requirements, can be broaden beyond the scope of your online store and leveraged to build a more comprehensive program (more on this in a different article).

The 12 PCI DSS Requirements and Their Relationship to the Goals

Goal	PCI DSS Requirements
Build and Maintain a Secure Network	1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data	3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program	5. Use and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures	7. Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data
Regularly Monitor and Test Networks	10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes
Maintain an Information Security Policy	12. Maintain a policy that addresses information security for employees and contractors

The thing to remember about these requirements is that they don’t “all” always apply, it’s ok to identify those things that are not-applicable, and it’s also ok to introduce compensating controls where applicable.

We also like to place emphasis on the goal itself, and while we might ensure each requirement is addressed, we always go back to the intent and ask ourselves – “What does this not address as it pertains to my environment?” We find this to be especially helpful, breaks us from the “checklist” mentality and ensures that we’re being honest with ourselves and the environment being secured.

In this article we stay broad, intentionally. The topic of PCI DSS is a mile wide and mile deep. But, we did want to take a minute to start with the basics before diving deeper into each area and how they apply to the online commerce world.

We encourage all readers to familiarize themselves with the specific controls that support their particular requirement by visiting the PCI SSC website www.pcisecuritystandards.org/. Although the expected release of PCI-DSS 4.0 is for mid-2021, the core goals and requirements will remain unchanged.

How Online Stores Benefit from PCI DSS Compliance

March 9, 2021 by Tony Perez Leave a Comment

The advent of e-commerce began mostly in 1995 with Amazon and AuctionNow (eBay). This was the beginning for payment gateways, payment aggregators and other payment support.

Since, there has been a continuous increase in demand for online purchases. It has created a substantial online payment space.

These days, online stores not only use the traditional payment gateways, but they’re also equipping themselves for future technologies. Introducing innovative payment methods, such as developing technology to embed payment-card information into the SIM card of cell phones, hardware device-based payment methods, contactless RFI based secure payment method, chip and PIN-based embedded smart cards shortly; there’s a lot to keep abreast of in the payment processing space.

Technologies Demand Improved Security

While businesses have adapted to new technological advances, they have not always applied the same level of energy into the security of those same technologies. Modern criminals recognize that an organizations desire to streamline a customers experience often dwarfs their desire to ensure it is secure. This translates into vulnerabilities being introduced, often unbeknownst to the business owner. That’s where things like PCI DSS can help.

About PCI DSS

In 2004, the payment card industry (PCI) recognized the importance of secure payment card operations and introduced global data security standards. This is referred to as the Payment Card Industry Data Security Standard, or PCI DSS, and applies to organizations that handle payment card data.

PCI provides a baseline against the Cyber Security, Information Sec, and Physical Security domains. The PCI DSS’s focus is to ensure that the Confidentiality and Integrity of the payment card data and supporting Information Systems are protected.

Why Online Stores Should Consider PCI DSS Compliance

Although PCI DSS is not law, it is a standard for all organizations handling credit card information and is mandated by the major credit card brands (i.e., Discover, Visa, MasterCard, AMEX).

Several countries and US states are starting to implement “PCI-like” laws to help protect consumers. In 2007 Minnesota enacted the “The Minnesota Plastic Card Security Act” and in 2009 Nevada enacted law that requires all businesses in its state to be compliant with PCI DSS in any instance where card information is collected.

With that in mind, there are several benefits online stores should be aware of to being PCI DSS compliant:

1. Improved Loss Prevention Foundation:

At the core of a businesses responsibility is to prevent the loss of money and company resources (e.g., customer data, proprietary information, etc..). A business, regardless of size, has a responsibility to reduce the potential security exposure and work to minimize the affects of a compromise if it does occur. Not doing so, can be costly to an organization.

For example, a compromise that includes a customer sensitive card information can lead to significant regulatory fines. These fines currently vary between $5000 to $100,000 per month until the merchants become PCI DSS compliant. It can also include being banned by various card providers.

Failure to prioritize things like a data protection program increases the risk of a compromise of personal data processing operations.

Some other potential business costs may include the following:

Forensic Investigation Costs;
Non-level one merchant gets defaulted to a level one merchant (ie.., it results in yearly onsite audits);
Merchant may be charged for card reissue;
Loss of ability to accept payment cards;
Increase transaction costs;
Removed from listing by payment brands;

Depending on how you look at your business, the cost savings could be interpreted as a return on security investments (ROSI) but in the world of security we prefer to think of it more as minimizing and improving loss prevention strategy.

2. Reducing Reputational Damage Control:

Many businesses have fallen victim to data breaches. A few high dollar value data breach cases were reported for Canva, Target, eBay, Equifax, LinkedIn, MySpace, Yahoo.

In early October of 2013, Brian Krebs, a security blogger, reported (https://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/) that the data breach at Adobe “appears to include more than 150 million username and hashed password pairs taken from Adobe.” This had also exposed customer names, IDs, passwords and payment information.

Within a couple of years, Adobe had to agree to pay millions in legal fees and settlement claims of violating the Customer Records Act and unfair business practices.

It was a breach of customers’ trust, which resulted in significant brand damage, directly impacting their share price and brand.

Given that payment card data is deemed personal data, and most data privacy legislation requires that businesses notify the affected people and the regulators, a public notice had to be sent out in this case.

Setting a “company-level tone” of security by default/security by design is an attempt toward protection against such data breaches.

3. Avoid a High-Risk Label

Post-breach, a business is required to carry out a forensic investigation to identify the root cause and is needed to invest heavily in the enhancement of their security defenses. The Card Brands escalate the businesses’ status to a high-risk (level 1) entity and subject them to a minimum of a 3-year onsite report on compliance (RoC) assessments.

The Regulators investigate the cause of the data breach and levy a fine. As seen in breaches like at Equifax, Morrisons Supermarket, Marriott, a business may also be subjected to private litigation.

4. An Organizational Security Framework

PCI DSS Controls Framework layers create an integrated approach for the protection of card payment channels. Fortunately, the PCI DSS heritage has a precise alignment with other cybersecurity controls frameworks.

Lessons learned from the PCI DSS integrated controls provide global data security standards defense of the business environment. For small online businesses especially, PCI DSS provides a basic framework from which an organization is able to build their security program.

5. Preparation for the Future

The PCI DSS is ever-evolving in accordance with new technologies and threats, with updates in security standards and practices; by being compliant, the merchants can enforce the most up-to-date processing practices for sensitive data processing business operations. This further enhances the Brand and protects the Reputation of a business while reducing risks of a breach of sensitive data assets or sensitive data processing systems.

The most historical data-breaches could have been avoided by adopting the “security by default” model.

The Use of Payment Card Industry Data Security Standards (PCI DSS) should be regarded as enhancing one’s business and not an annual “checkbox” audit. Handling highly sensitive client information is a huge responsibility and should be taken seriously.

All businesses, regardless of size, handling credit card information have a compliance obligation. While not all do, we hope this article helps highlight some of the other business specific benefits that help organizations of all sizes mature their security program.

Secure a VPS to Manage multiple Websites – Part I (Isolate Users and PHP)

August 13, 2020 by Tony Perez Leave a Comment

If you are an agency building websites for your customers, and managing those sites on a Virtual Private Server (VPS), this post is for you.

While working on a recent forensics case, we encountered one of the most egregious mistakes we see with organizations managing multiple websites on one server.

All websites were owned by the default web server user and group.

[Read more…]

Leverage OSSEC as a Syslog Client or Server

May 19, 2020 by Tony Perez Leave a Comment

Open Source Security (OSSEC) is a Host-Based Intrusion Detection System (HIDS) that allows you to quickly collect, analyze and correlate events across your entire infrastructure. It can be deployed on any endpoint, from network based tools (e.g., routers, switches, etc..) to end points (e.g., servers, desktop, laptops, etc..).

System Logging protocol, (Syslogs), is a mechanism used to collect, package and send data from a client machine to a server machine. This server machine is typically a Syslog Server.

While helping a customer think through their logging solutions and requirements, we realized that many OSSEC users fail to realize that OSSEC has the ability to function as both a Syslog client and Syslog server.

This is a technical guide that explains when a deployment might require this type of configuration, and how to extend your OSSEC deployment to fully capitalize on the platforms capabilities.

Accounting for Busy Nodes / Networks

Leveraging OSSEC as a syslog client allows you to divide activity across different networks, while still leveraging the power of OSSEC.

Imagine a world where you have a different networks (Zone 1 and Zone 2). Zone 1 is extremely busy, generates in excess of 10 million requests a day. Zone 2 is quieter, generating a few hundred requests a day. Maybe Zone 1 is your web environment, leveraging complex configurations that account for load balancers, databases, web servers, etc.. Zone 2, however, is a cluster of desktop / notebook machines.

Example Network with Different System Boundaries (Zones)

The task is to collect and aggregate all the data into a centralized manager so that you can perform your duties.

One option might be to deploy a normal Agent / Server deployment that would have all events consumed into one manager. Another, less used option, would be to deploy two Agent / Server configurations, where one Manager is subservient to the Master.

There are a couple different benefits of this deployment:

Easier management of agents (allows you to group devices and data);
A network / device that is yielding excessive logs, this configuration would pre-parse locally to parse data that matters to the master;
Centralized control of all networks (assume you have multiple networks you’re managing).

This configuration allows you to isolate, process, and parse the information that makes sense.

In the example above, Zone 1 could have its own Manager that collects, analyzes and correlates activity across the network, and it can be done independent to what is happening on Zone 2. The manager in Zone 1 can then send the processed data to the Master manager. This ensure that you’re accurately collecting, and storing the event data that matters, while be responsible and cognizant of the potential load on your network.

This configuration is extremely powerful, and helps you be more efficient in the management of your event data. Below I’ll share some tips on how to make this work.

OSSEC: Syslog Client and Manager

Any OSSEC deployment (e.g., Agent, Manager, Hybrid) can function as a Syslog client, but only the manager can function as a Syslog manager. This is an important distinction.

Convert OSSEC Install Into a Syslog Client

First, you want to enable syslog client on your OSSEC install:

/var/ossec/bin/ossec-control enable client-syslog

This will enable the syslog client in OSSEC. In the example above, we did this on the OSSEC manager.

Once enabled, update the OSSEC configuration file to make sure it knows where to send the data:

vim /var/ossec/etc/ossec.conf

Add a new section in the configuration file for syslog.

<syslog_output>
  <level>6</level>
  <server>[public IP of manager]</server>
  <port>1515</port>
</syslog_output>

This is going to allow you to take control of what gets sent to the Master server. Above I use three key options: level, server, and port.

level -> defines what alert level should be sent to the manager, extremely powerful as it allows you to reduce the noise being sent to your master. In the example above, I select to only send alerts that are level 6 or higher.
server -> is the public IP of your Master.
port -> The port you want to send the information too. The default port for syslog with OSSEC is 1515.

What’s really unique about this is that it is going to allow you to leverage your OSSEC alerts, which have already processed and built intelligence from the events, and send that to your master in tact.

Last step is to reboot OSSEC on this end poing:

/var/ossec/bin/ossec-control restart

To verify the data is being sent, do a simple TCPDUMP and track the outbound requests:

tcpdump -i eth0 -nnn -s 0 -A udp port 1515

OSSEC Manager as a Syslog Manager

On the Master manager, configure it to accept the new syslog files.

To configure the Manager as the Syslog manager simply enable syslog connections on the manager. You do this by editing the OSSEC configuration file:

vim /var/ossec/etc/ossec.conf

Create a new remote entry using the following options:

<remote>
  <connection>syslog</connection>
  <port>1515</port>
  <allowed-ips>[public IP of syslog agent]</allowed-ips>
</remote>

This is going to allow the manager to consume the events from your syslog client appropriately. In this instance, another OSSEC manager. Above, I used three options:

connection -> Tells OSSEC to expect syslog data.
port -> The port to expect the events. The default port for syslog with OSSEC is 1515.
allowed-ips -> Identifies where the events are coming from, needs to be the public IP.

You can confirm things are functioning by running a similar TCPDUMP on the manager, or you can parse the the ossec.log file for details. Here is one way:

cat /var/ossec/logs/ossec.log | grep syslog

You should see something similar to the following:

2020/05/18 20:59:24 ossec-remoted: Remote syslog allowed from: ‘[public IP of the syslog agent]‘

2020/05/18 20:59:30 ossec-logcollector(1950): INFO: Analyzing file: ‘/var/log/syslog‘.

When it’s all done, you will see an entry in your agent control for the new syslog connection.

/var/ossec/bin/agent_control -lc

It will be displayed like this:

List of syslog-based sources: ID: na, Name: [hostname]->[public IP], IP: [public IP], Syslog-based Active

OSSEC is one of the most powerful open-source solutions available to any organization to help them with their collection, aggregation and analysis of event data. What it lacks in aesthetics, it easily makes up for in its economics, functionality and relatively low footprint. .

If you’re managing your own OSSEC deployment, need help thinking through its deployment, or need help sustaining your existing deployment ColdPath is here to help you. Contact us via our Contact Page, or send us an email at info@coldpath.net.

Recovering Servers Post-Hack

April 22, 2020 by Tony Perez Leave a Comment

After a hack, should an organization restore its servers from a new OS or from the backup?

We were recently helping a hacked organization and this question was asked. The organization had been given two very different opinions, and wanted to know what we would do. The recommendations they had received came from two polar opposite ends of the spectrum.

One group said, “yes, absolutely, you must use a new OS and migrate the data,” while others said, “you’ll be fine to restore from a backup, just be sure the patch the vulnerability.”

Our response was a bit different – it depends.

This post expands on why our recommendation could be perceived to be ambiguous, but hopefully provides a framework that you can leverage when your organization is presented with the same question.

Balance Security Recommendations with Business Needs

To understand the recommendation, you need context:

This was a decent sized business with close to 100 servers compromised. The bad actor was able to deploy ransomware, and was holding the organization hostage for a ransom. These servers were the core of the company, it included all business functions (e.g., HR, Finance, R&D, Operations, Marketing, Commerce). The specific size in terms of head count, or revenue, doesn’t matter, but it’s important to note that they did not have a dedicated security team (but there did exist a person whose part-time job was security) and lacked basic security knowledge.

What we learned through the process is that the organization had no way of knowing a) the vector used to exploit the environment, or b) when the attack actually started.

What this tell us is that you have to assume worst-case, and worst case would undeniably require you to start with fresh OS installs. The problem, however, is can the business support a move like this?

This reminds us of our jobs as a security professional; we exist to help the organization achieve its business objectives, not the other way around. We help organization identify risk, and help implement controls to help mitigate those risk so that the business can continue to do its work. Post-compromise, that objective doesn’t change, in fact it expands. We not only have to identify and eradicate the issue, but also have a responsibility to ensure business continuity.

To appropriately give an answer on what needs to be done, you have to understand some very basic facts about an organization:

Does the organization have a security team?
Does the organization have a team required to spin up the new environment?
Does the organization have the technical expertise?
What are the specific configurations difference between the old environment and new environment?
What kind of servers are we talking about?
How long would it take (in hours / days)?
What is the real confidence level of the estimate?
Can the business afford to be down the projected time frame?

We have yet to meet an organization that meets these criteria that has had solid answers to any of these questions. And so, how you approach the problem must take these insights into consideration.

There is what they must do, and then there is what they can do. Our job in security is to help figure out the “how”.

Concepts That Establish a Foundation

An organization is often unable to answer the most basic questions post-compromise. This means that, while we can all agree that the desired end state should be fresh OS installs, the big variable we need to account for is time.

In a deployment like the one this organization was in, what is needed is a practical, phased, approach to how, and when, they go live. Which is why our recommendation was more grey than black and white.

The recommendation we provided was that they wanted to do both, but in a phased manner and it was built on three concepts:

Categorization	A basic process of putting things into “categories” “groups” “classes” or some other similar bucket.
Functional Isolation	Stems from the world of electrical circuitry where you isolate components. We use it when talking about networks and systems to represent the same thing – isolate the function of a network, isolate the function of a server (i.e., a web server shouldn’t be print server, shouldn’t be an email server, let it serve one function).
System Boundaries	This is a term used in system design meant to represent the logical lines (“boundaries”) that help separate different environments.

The biggest issue the organization is faced with is it doesn’t know how the attack happened.

In hindsight, they were able to identify a series of Indicators of Compromise (IoC) that pre-date the actual hack by a couple of weeks. This conforms to what we know of the tactics, techniques and procedures (TTPs) employed by bad actors, but falls short of providing a definitive answer around what happened. The organization is also limited in their forensic ability, it lacked any logging / activity tracking, and their backups were part of the compromised servers. Each of these contributes to the general consensus, that yes, they do want fresh OS installs.

It forces you to assume worst-case. But the business has a need to get operational, quickly, ensuring business continuity. This is where you must balance desired end-state with reality, learning to balance security with the business needs.

Fortunately, security professionals can help mitigate the risk.

Mitigating Exposure

The number one risk the organization must be aware of is that they might suffer a compromise the minute they spin back up. Bad actors are known to deploy their payloads within a network that allow them to bypass access mechanisms and defensive controls. This is the reality you must deal with when you don’t know how a hack happened.

As such, your focus is not so much about preventing the hack but reducing the potential impact if, when, it happens again.

This can be mitigated by using a phased approach, one in which they establish new system boundaries that are functionally isolated and based on a hierarchical categorization scheme.

1. Categorize the Servers

Servers should be categorized based on their impact to the business.

A well recognized categorization scheme is: Low (L), Moderate (M) and High (H).

The most difficult part of this process is assessing what belong in what category. The following calculation should be employed:

Security Category (SC) = 
{(confidentiality, impact), (integrity, impact), (availability, impact)}

This model makes use of the security triad – Confidentiality, Integrity and Availability (CIA) that speaks to the three core security objectives

Example of how it can be applied:

A department file server contains both sensitive personnel information and routine administrative information. The following are possible security categories for the information on the file server.

SC personnel information = 
{(confidentiality, M), (integrity, M), (availability, L)}

SC administrative information = 
{(confidentiality, L), (integrity, L), (availability, L)

The resulting categorization of the file server would be the highest level of categorization for each type of information or data on it.

SC file server = 
{(confidentiality, M), (integrity, M), (availability, L)}

Which would mean that the file server is categorized as Moderate.

This is probably the most consuming part of the process.

2. Reduce Function Where Possible

The categorization process should shed light on what each server is doing. This is an opportunity to identify those that should be repurposed to reduce its functionality where possible, i.e., system functional isolation.

3. Establish New Boundaries

Once you have your servers categorized, you can establish new system boundaries. These boundaries are basic logical groupings of each category and help you better understand your environment.

4. Isolate System Boundaries

Once you have those boundaries, you must take the time to perform two critical functions (i.e., network functional isolation):

Review access controls;
Review user groups;

The biggest mistake organizations make that allow for this level of compromise is a systematic failure of how roles, the associated responsibilities, and access are managed.

The new server categories present an opportunity to review how its roles / responsibilities are designed and implemented. It should force you to ask tough questions around who needs access to what systems. It should also force you to asses how information flows between the various system boundaries.

A basic construct would ensure that communication between systems is not allowed across different levels at a minimum, but should introduce additional controls (e.g., firewalls, access constraints, MFA) within boundaries as well.

This is also a great time to spend time on access control itself. What level of authentication is being employed?

The more critical a system, the important it is to ensure appropriate checks and balances are introduced. This is where things like Multi-Factor Authentication (MFA) become extremely important. If you’re interested to learn more about MFA, I encourage you to read the series of articles prepared by my friend Jesper Johansson on the subject.

5. Phased Deployment

The first three steps help you design and implement a plan of action based on the first four steps of this process.

This approach highlights the sequencing of events. It identifies how specific environments should go live.

Servers that are deemed critical, based on your categorization calculation, should not go live with a new OS, while those that are deemed less impactful to the business have the ability to go live with backups.

This approach provides your business a very practical system that helps balance the potential risk and the need for business continuity.

Working in a World of Unknowns

As security professionals the business does not serve us, we serve it. We must educate and inform those responsible for the business, and it’s our responsibility to adapt and help come up with creative solutions that help align to the ultimate objective – run the business.

We must not be rigid in our thinking, instead we should tailor our ideas accordingly. In the world of security we will rarely have enough information.

The scenario above helps illustrate what this means.

Both consultants were right in the desired outcomes, but wrong in the absolute nature of the proposed sequence of events. Taking into consideration the full scope of the compromise, and state of the business, helps us create unique approaches that helps achieve the same outcome over a period of time, while also helping to reduce the risk of a new compromise.

When we work in a world of unknowns all we can do is make the best possible decisions under the current circumstances.

My Company Has Been Hacked – What do I do?

April 13, 2020 by Tony Perez Leave a Comment

Over the past decade we have helped countless organizations respond to security incidents around the world. There is a common theme each time, with exception to large enterprises with an established security team, most small businesses have no idea where to start.

The following article will help expand on some of the lessons we’ve learned over the years. It will help provide the practical recommendations that we have used to help guide companies through their most vulnerable period.

This guidance will be most valuable to organizations that fit this criteria, but there is a lot of value that micro-businesses can also take from this.

Total Revenue	$1M – $20M
Total Employees	< 500
CISO / Security Leader	No
Security Team	No, or < 5
Security Governance	No

Most applicable business segment that can value from this.

Incident Response Foundation

The key to responding to an incident is having a basic foundation from which you’ll operate. For a small business that has never experienced a compromise before, you’ve likely never felt more vulnerable. A foundation will remove the emotion from the equation, and help you function rationally.

The minute you realize you have been compromised there are a series of questions you should immediately ask yourself, your team:

What is the scope of the compromise?	Understanding the scope of the compromise will help you figure out your response, and who needs to be involved. You won’t always know the answer up front, but it’s a question you’ll want to continuously ask. Note that scope will change through the entire process. You might realize the scope was not as bad as you initial though, but it might also be a lot worse. The big question that should be at top of mind: 1. Have customers been affected? 2. Has PII been affected? These two questions will have implications both for privacy and data breach laws across multiple jurisdictions and regulatory bodies (depending on industry).
Who is taking ownership?	If everyone is leading, then no one is leading. You need to assign roles and responsibilities during any compromise. Who is the one making the decisions? Who do I go to for information? One of the biggest mistakes executives make is assume they are in control, and they have the need to work directly with the operators. They MUST know what is happening every minute! This can’t be further from the truth, as a leader you are definitely a stakeholder but you’re not necessarily the operator in charge.
What is the communication cadence and medium?	Identify how information will be communicated to all the stakeholders. Will you use an asynchronous form of communication via a medium like Slack, Teams? Will you use email? What will the communication frequency be? Will you do updates every 30 minutes? every 60 minutes? When must information be shared?

Three Questions to Ask the Minute You Become Aware of a Compromise

Incident Response Work Streams

The minute you become aware of an incident, it should be all-hands on deck for those teams that have the ability to make a difference. If your team can’t make a difference, then your responsibility is to get out of the way.

Clearly assigning ownership will help with this process. This person should function as the buffer between the stakeholders and operators. They will also be responsible for managing the various streams of work that must kick-off the minute a compromise is identified.

Example of Post-Compromise Work Streams Across Different Functions

The table is not designed be exhaustive, but it is meant to provide a foundation from which any organization can start regardless of industry.

Ok to Run Parallel Work Streams

Most of these jobs can be performed in parallel.

For example, one step that a lot of businesses often forget during the initial phases is to enlist the help of law enforcement and their insurance provider (assuming you have Cyber Insurance). In the US for example, you can engage your local FBI office depending on the scale of the impact.

Another great example is communication. Communication itself can have a series of other streams and can be divided between internal and external communications. While the technical teams begin their investigative process you can have a separate team start preparing artifacts for best and worst case scenarios so that they are ready once the information is available.

Security Breach Notifications Laws / Rules

One of the biggest things you want to be cognizant of are the various laws that exist across different jurisdictions around data breaches and your responsibility to notify partners, and customers. It’s why understanding the scope of the compromise is critical.

In the United States, all 50 states have their own legislation that you have an obligation to confirm with. The best resource we have found to stay up to date with the changes is the National Conference of State Legislatures.

Additionally, organizations need to be considerate of their industry and their obligations under whatever regulatory body they have to conform too (e.g., PCI DSS, HIPAA, ISO 27001, FISMA, etc…).

Handling the Incident

The steps involved in handling an incident requires its own article, but in the interim I would refer you to a great guide by the National Institute of Standards and Technology (NIST) on Computer Security Incident Handling.

In this guide they outline four very distinct phases of the incident response life cycle:

I like this guide because it is simple, and practical. Something, any organization can easily follow, but still highly effective. It also highlights one very critical principle – security is a continuous process. Most importantly, it highlights the importance of post-incident activity in which you learn from what has happened and improve your security program.

The Chaos of Incidents

We can say without a doubt that in every incident we have handled over the past decade, there is always this feeling of dismay amongst the companies we work with. It doesn’t help that they always happen in the middle of the night or right as you’re going on holiday. You will also find yourself frustrated with mistakes you made, or information you don’t have (secret: you will never have enough information).

Know that this is all normal, and expected behavior.

This article will help you orient yourself. It should provide your organization a basic foundation from which you can lead your team through whatever incident you’re facing.

A Website Security Framework Intro

April 10, 2020 by Tony Perez Leave a Comment

A framework should provide the underlying structure from which we built our security governance program.

Consider a home. Regardless of the type of home, they all have a similar framework. The framework keeps the house together and defines the basic structure, it starts with the foundation on which the house will sit. From there, the developers and architects build and expand it into something that fits their specific requirements. Without a basic framework, the house will collapse, the same applies to your organizations security program.

The security problems we face today are more often than not attributed to human behavioral problems, more so than technical ones. We invest a tremendous amount of energy into the latest technologies, deploying controls designed to mitigate risk, and yet we all continue to suffer from compromises. It’s not that the technologies don’t work, but rather that our approach is flawed; it lacks the structure required to adequately account for the emerging threats.

Attackers are successful not because we’re technically incapable, but because we are behaviorally weak.
Tony Perez | @perezbox

Something I learned at GoDaddy / Sucuri was that the tools we built (e.g., CDN/WAF/Backups/Remediation) were one piece of a larger puzzle. It’s not that our product wasn’t effective, but that the businesses leveraging the products lacked a basic understanding and appreciation for basic security principles. Tools would be employed with no structure in place to define why they are being deployed.

Take into consideration the organization that deploys a Web Application Firewall (WAF) to mitigate external threats by virtually hardening and patching at the edge. Sounds fancy, right? And technically works great! Until you learn that the same organization doesn’t block direct access to the server. In other words, an attacker can access the site directly, bypassing the defensive control.

We have to do a better job of bridging the divide between the knowledge that today’s webmasters have, and those that they require to effectively manage their websites security. We do this by starting with the basics – let’s create a basic Website Security Framework that any organization, regardless of size, can employ.

A Basic Website Security Framework

The basis of this framework is not new. It’s borrowed from the Framework for Improving Critical Infrastructure Cybersecurity, developed by the US National Institute of Standards and Technology (NIST). The idea is to educate users on a framework that already exists and can be easily leveraged for your organizations website security needs.

It is built on 5 core elements: Functions, Categories, Subcategories, and Informative References. Their relationship is as follows:

The functions are designed to organize the key security domains you should be considering. Keep the functions to these core five domains, do not over complicate.

As the illustration shows, the categories are subdivisions of the functions, and the subcategories subdivisions of categories. There is a one to many relationship between Functions and Categories, and Categories and Subcategories. The informative references have a one to one relationship with the subcategories, they are important to ensure that everyone is aligned with the exact steps being leveraged for each control and action.

Improving An Organizations Security Posture

Before deploying security solutions into your stack ask yourself what your general disposition is towards security. The framework above is designed to help you in this process.

As you consider the framework, think of security as a continuous process. The threat landscape is constantly evolving, your security posture should also evolve. Revisit the process at some interval (e.g., weekly, monthly, quarterly). It’s not about the frequency as much as the simple act of actually revisiting the process.

It can feel over-whelming when you first start thinking about a framework for your organization, which is why we recommend breaking it down into bite-size chunks. The easiest, and most difficult, is always the identification step.

In my experience, rarely does an organization have a good handle on what they really own. You can’t protect what you don’t know exists.

Things to consider through the process:

When was the last time you created an inventory of?
What is your technical stack?
Who knows what your technical stack is?
How many domains are part of your brands portfolio?
What does supply chain look like for your various digital assets?
What systems / services are you dependent on?
Where are they hosted?
Who has access these environments?

We do not get hacked because cyber criminals have an advantage over us, or because of the platforms we use. We get hacked because we lack basic knowledge, and in some instance complacent. We fail to take the basic precautions required when introducing a new property to the greater internet ecosystem.

ColdPath is here to partner with your organization and help navigate the process.