Capital One Breach, Misconfigurations, and Insider Threats

While the Capital One data breach was not targeted at the healthcare industry, characteristics of the attack have sadly become commonplace in health systems throughout the world. One can also be certain that patients are listed among the approximate 106 million breach victims.

To recap what became big news yesterday, Capital One reported a breach of its systems due to the exploitation of a vulnerability in a misconfigured application firewall. As a result, an individual accessed the storage on an Amazon Simple Storage Service (commonly referred to as an S3 bucket) and absconded with approximately 106 million credit cardholder records, including some social security numbers, transaction histories, and credit card application information.

Many technical questions have yet to be publicly answered, including:

• What were the details of the misconfigured web application firewall that allowed access to S3 buckets?
• Were data exfiltration patterns being monitored adequately?
• What kind of encryption was in place, not only at the file level but also at the bucket level? Was the data itself encrypted or hashed in some way?
• What were other controls put in place on those buckets to prevent unauthorized access?
• Was the perpetrator able to use a set of user credentials to get into the buckets? Or were the buckets themselves accessible to the public?

We do know S3 part of the system, and at ClearDATA we know a thing or two about securing S3 buckets. While Capital One states that the issue stemmed from an application firewall misconfiguration, those less familiar with S3 can become victim to the following S3 misconfigurations:

• Permissions can be broad or narrow. For sensitive data, please make permissions as narrow as possible.
• Encryption comes in three flavors for S3. The right flavor should be applied for the right use case and data. Choose carefully.
• Audit logging: S3 buckets do not save audit logs by default. Enable file level audit logging and save the logs to a central location.
• Data classification: The S3 bucket should be configured according the classification of the data within it.

I urge you to review this S3 article written by my colleague titled 4 Common S3 Misconfigurations to Avoid.

This massive breach was orchestrated by what appears to be a malicious insider.

Just what is an insider threat? An Insider is an employee of a company that has greater access than others to sensitive information. The insider also has an understanding of internal processes, knowledge of high-value targets, and awareness of potential weaknesses in security.

An insider attack can cause significant, even catastrophic, damage to the targeted IT infrastructure.

So how can you be on the lookout for an insider threat at your organization? What are some common symptoms?

The US Department of Homeland Security has some characteristics of insider threats. They include:

• Introversion
• Greed or financial need
• Vulnerability to blackmail
• Compulsive or destructive behavior
• Rebellious or passive-aggressive behavior
• Ethical “flexibility”
• Entitlement – narcissism (ego/self-image)
• Minimizing their mistakes or faults
• Inability to assume responsibility for their actions
• Intolerance of criticism
• Self-perceived value exceeds performance
• Lack of empathy
• A predisposition towards law enforcement
• A pattern of frustration and disappointment
• History of managing crises ineffectively

Please don’t mistake these characteristics for the requirements to run for Congress. We’re not talking about politics today.

However, beyond the list of characteristics, what can you look out for day to day in your work environment? Here are some indicators of insider threat activity. Take note when an employee:

• Remotely accesses the network while on vacation, sick, or at odd times
• Works odd hours without authorization
• Has notable enthusiasm for overtime, weekend, or unusual work schedules
• Unnecessarily copies material, especially if it is proprietary or classified
• Has an interest in matters outside of the scope of their duties
• Shows signs of vulnerability, such as drug or alcohol abuse, financial difficulties, gambling, illegal activities, poor mental health or hostile behavior

We can assume from online postings that the perpetrator in this breach had some self-professed, self-destructive impulses. She allegedly worked for AWS for several years but has struggled to find steady employment since [1].

According to the SANS Institute, “one of the toughest and most insidious problems in information security, and indeed in security in general, is that of protecting against attacks from an insider” [2].

So, what can you do to protect your company from an insider threat:

• Deploy data-centric, not system-centric security – identify and classify assets and deploy data security controls.
• Know your data, where it is stored, how ‘it’s accessed, who protects it, how much exists, and how it is backed up
• Crowd-source security (everyone must protect data)
• Determine who has access to which assets – Review and reevaluate this list regularly – ensure that only those who need access – have access
• Assign system owners and custodians. The owner decides who has access and for which purpose, while the custodian is responsible for maintenance, security, and administration of the system and follows the directive of the owner
• Use positive social engineering
• Build a baseline based on volume, velocity, frequency and amount based on hourly, weekly, and monthly standard patterns
• Use centralized logging to detect data exfiltration near insider termination
• Require identification for all assets (e.g., access cards, passwords, inventory check out)
• Note frequent visits to sites that may indicate low productivity, job discontent and potential legal liabilities (e.g., hate sites, pornography)
• Abide by the principle of least privilege
• Segregate, or divide duties
• Periodically audit your systems
• Provide a means to report violations

And by all means, encrypt your data in transit, at rest, on the storage medium, and at the data layer. In turn, securely manage your decryption keys.