Machine Learning – Intelligent Security Data Analytics

Ran across a fascinating TED video which provides insight into just a close we are to meaningful security data analytics.

Machine learning systems within the last year now process images, signs, and information with more accuracy than a human. The extraordinary Deep Learning algorithm allows scientists to build learning systems without prior knowledge of the subject and solve previously unsolvable problems. Unsolvable… not because of computational power limitations… but because people don’t know how to solve the problem. The machine, however, can learn about and figure out new ways of solving problems that people have not yet thought about. This is different from programmatically writing the logic for how to solve problems.

Consider speed and analysis of system operations with accuracy and capability beyond what a human being can process, scaled to consume the entire output of the data centers operational output (errors, logs, alerts). This is beyond building rules to identify bad traffic and malicious events. This is about enabling a deep learning machine to read every known book, website, web forum, data feed, dark web content, and become a security powerhouse with ultimate knowledge of your data center.

Sound crazy? Far-off? Watch the video below.

The Wonderful and Terrifying Implications of Computers That Can Learn

Jeremy Howard
 

The Emerging Recognition of Governance

Thank you Verizon. Fantastic report. The authors did a wonderful job and my hat is off to you. Thank you Dark Reading. Thank you twit.

Governance really is THAT important.

Security used to look something like this… https://www.youtube.com/watch?v=D0n8N98mpes. Then organizations started to focus on compliance when Sarbanes-Oxley and in PCI became mandatory and prevalent. Security professionals realized that compliance in and of itself wasn't enough, and the focus shifted to addressing risk. Problem is that people still feel like they are playing Wack-a-Mole. The governance problem started becoming… A problem. It grew geometrically with the number of different new systems, vendors, applications, interconnections, interfaces, and dependencies.

During the lifecycle of the system there are different security and risk challenges that must be solved, such as those described in context of a PCVMR Cycle, which recognizes the importance of maintaining the system over time.

Let's look at operational hygiene, or governance, in the lands of a state security model. You start at the 0 when the system has been validated/authorized for operations. Ideally at that moment in time the system is fully secure without any flaws. You've tested the system against known attacks and established that the system is properly secured to your baselines. Over time, however, the adjusted state for where you should be is a slight trajectory upwards with some growth to recognize changes in security posture/configurations, architecture, design, firmware, patches, control inheritance, additional solutions, etc.

Compare the state of where you should be vs. the day 0 configuration and what you find is that over time you have a greater gap. Let's call this current state vs. secure state gap "drift". The drift/gap gets larger over time, and leaves you susceptible to compromise. Now go back and look at the wonderful statistics the Verizon team put together and read the column in red.

Does compliance = security? Depends. Depends on whether you recognize a properly implemented risk management framework as necessary to meeting the compliance requirements. Depends on whether you recognize compliance requirements must be managed over time. Depends on whether you have the right people who understand, processes that enforce, and tools that execute and track governance of your systems.

Discussion of SCADA and Multitenant Environments

Here's a reminder that a technical control failure can be driven by management/administrative and/or governance failures. Recently, a conversation focused on multitenant environments handling very different data types and sensitivities.

I would not put SCADA/PLC power distribution control systems on the same physical frame as consumer payment processing or anything else externally accessible. It's not simply a matter of whether the system can be secured. It's a matter of who is ultimately responsible for the security of the system. The security of the system is going to be hard enough. If there is confusion as to who is responsible for system security, then you significantly increase the likelihood of control failures from system drift over time.

"We've got you covered!" Be careful. Be very very careful.

Very interesting day today listening to a vendor discuss how they have security covered. To hear them speak, you would think that they have covered security from soup to nuts. In ways that you can only fathom imaginable.

Read the fine print.

Better yet. Read your authoritative sources, risk management process findings, and understand your own requirements.

Three years ago I enrolled my little boys in MMA classes. They enjoyed it so much that I very soon got them started in private lessons with a professional UFC fighter. What I found to be fascinating was that despite his repertoire of tricks and experience, he often went back to the basics of what was necessary to succeed in a fight. Sure, the extra stuff can take you over the top. But if you don't understand the fundamentals, you're setting yourself up for failure.

Security is the same way. You can look at all of the new bells and whistles on the market, but if you can't execute on the fundamentals, you're setting yourself up for failure.

Perhaps one of the more interesting moments I've had in this industry came when a friend simply said to me, "Chris, this doesn't have to be that difficult. As long as you can control access to the data, you win. Every time."

On the surface of it, this is true. However, executing this idea is more than just access controls. He knew this, and that led into the discussion of the different vectors which were either a path, or gateway component, for access to the data and exfiltration of the data. The network is a critical piece of this architecture, and absolutely must be secured with appropriate access controls, intrusion prevention, network behavior anomaly detection, etc., etc..

Other things to consider include endpoint protection, log collection, log analytics, data loss prevention, and other controls that identify a potential compromise in the secure state of your system security. Don't lose sight of the big picture. Keep in mind the comprehensive set of controls necessary to protect access to data, inclusive of context. Subject. Data object. Paths. Demarcation points.

Remember technology affects every part of the infrastructure. At its best, security is a competitive differentiator. At its worst, security is your competitors differentiator.

Significant Update to SP 800-53a – Building Effective Assessment Plans

Released 12/11/14…

SP 800-53a is the sister document to SP 800-53.

 

NIST Special Publication 800-53 Revision 4

This document is the body of controls.

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
• Security and Privacy Controls for Federal Information Systems and Organizations

NIST Special Publication 800-53A Revision 4

This document provides guidance on how to assess – test for compliance – each control outlined in the body of controls.

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf
• Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans

BAD USB Opportunities and GOOD USB Drives

The first thought that immediately came to mind wasn't so much just counterfeit or cheaply made USB devices, but also USB chargers. We plug our android, blackberry, and iPhones into inexpensive chargers bought off Amazon.… Makes me wonder if it's really a good deal. Or just an incredibly wonderful opportunity for a nationstate that manufactures those devices and already understands this and many other exploits capable of going unnoticed.

Reading articles such as this well-written bit by Cory Doctorow, thinking about Cottonmouth, and considering the pervasiveness of potential compromised devices.... you can understand the effectiveness of this attack vector. Then consider the likely reuse of these compromised devices. They are going to be around for a long, long time.

GitHub Link: https://github.com/adamcaudill/Psychson

By the way, trusted USB devices… Excellent opportunistic marketing for a device that was ahead of its time... Smart company.

IronKey USB Drives

• http://www.ironkey.com/en-US/solutions/protect-against-badusb.html
• IronKey Enterprise 250 flash drives are FIPS 140-2 Level 3 validated with AES 256-bit hardware encryption.
• Enforce device-specific policies and mitigate risks of data loss by remotely disabling lost or stolen drives.
• A ruggedized, waterproof metal chassis resists physical break-ins and is tamper-proof.

If you work on a security or audit team – take advantage of the perks that come along with the position and apply for a free evaluation: http://resources.imation.com/ikenterprise-evaluation.

What's in a Name? Shell Shocked. Deserves a 10.

This one deserves a 10. This is in regards to http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271.

Original release date: 09/24/2014

Last revised: 09/24/2014

Source: US-CERT/NIST

Overview

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Impact

CVSS Severity (version 2.0):

CVSS v2 Base Score: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend)

Impact Subscore: 10.0

Exploitability Subscore: 10.0

 

MAC vs DAC vs RBAC

Recently had a discussion regarding mandatory access controls, discretionary access controls, and role-based access controls. The goal of the discussion was to discuss and understand use cases in the context of risk – which is driven by the business impact of a loss in the confidentiality, integrity, or availability of data.

Take for example an environment that does not handle sensitive data whereby a loss in confidentiality would have significant and sustainable impact. However, there are situations in which the delivery of the processed data is mission-critical for the company to continue operations. Therefore, a violation of the integrity of the data or availability of the data would have significant impact.

Discretionary Access Controls (DAC) and Mandatory Access Controls (MAC) describe the permissions required to access an object in relation to other objects. Role Based Access Controls (RBAC) simply describes the grouping of identities and application of permissions to those groups. The Reference Monitor (RM) concept and requirements still apply when building the environment, such as situational context, forensic auditing, and visibility into permissions.

DAC suggests someone can give you access to an environment, and you have free reign within that environment without knowledge of any particular object sensitivity. Your permissions are governed by your identity.

MAC suggests that in addition to permissions associated with your identity, every object inside the environment has its own label associated with the object. Now, based upon permissions granted to me, perhaps associated with my role or group, I can only perform actions on tagged objects if an explicit policy grants me access to the object. Conversely, a policy can be written based upon tags/labels to explicitly deny me (or my role/group).

[UPDATE] Go here for a more recent illustration: http://www.cloudauditcontrols.com/2016/01/quick-fly-by-of-access-control.html.

Quiz: What do these companies have in common?

This was some quick research simply to prove a point. Security is important to your customers. If it's not, then it should be.

 

Highlight of a recent conversation with a Fortune 500 company who called me while I was at DEFCON. Network team, firewall team, and others were on the call. They have special awards for companies like this.

 

Customer: I need ports, protocols for the administrative network.

Me: Excellent. Not a problem. Can you explain the use case?

Customer: It's for DMZ access.

Me: Are you going to expose the management network to the DMZ?

Customer: Yes.

Me: On the face of it this seems like a really bad idea. This is a massive compute platform. Can you explain what kind of segmentation you have inside the DMZ?

Customer: I have no idea what kind of segmentation we have inside the DMZ.

Me: At this point I could do one of two things. I can either give you the information you want and trust that you have a security team that will look into this, or I can recommend you take a step back and understand what you are trying to accomplish – including the potential risk implications.

Customer:… Silence… Maybe we should set up a meeting…

Okay – onto the quiz.

 

Question: What do these companies have in common? 

• The Home Depot
• JP Morgan Chase
• UPS
• REI
• CVS/Caremark
• Rite Aid Pharmacy
• Northern Trust Company
• Wall Street Journal
• Bank of America
• Apple
• Goodwill
• CNET
• Boeing
• Lockheed Martin
• Goldman Sachs
• PF Chang's
• AT&T
• Walgreens
• And 100+ more that were fortunate to find something special.

What happened?
Over what time period?

Hint…Quote from Olaf...
“Oh, I don’t know why, but I always loved the idea of summer, and sun, and all things hot.”

https://www.youtube.com/watch?v=UFatVn1hP3o

 

 

Answer: Summer 2014 – these companies were burned by a data breach.
http://www.privacyrights.org/data-breach/new
 

Documenting Privilege – PCI-DSSv3

Yes, I understand the importance of Requirement 7. Restrict access to cardholder data by business need to know.

Increasingly, my respect grows for peers that communicate in plain English. Why? Because I understand how well you must understand material to [1] discuss it vs. [2] discuss it plainly.

Several years ago I was listening to a public radio tribute for a great Nobel prize-winning physicist. He had recently passed away, and his mark on society wasn't just his great research. It was his ability to plainly explain complex concepts in a way that people understood, and in a way that excited people. Creative passion. Made people want to understand and know even more. He made physics accessible to the average person.

Like many of you, I'm asked to understand a wide variety of topics. That means that I'm often coming back to topics that I've worked with before, and noticing new things.

As an example, requirement 1.1.5 is nicely done:

• Requirement 1.1.5
• Description of groups, roles, and responsibilities for management of network components
• Testing Procedure
• 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components. 
• 1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.
• Guidance
• This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged. 
• Plain English: Validate everything is managed.… No device left behind… 

 

Now here's an example of much-needed simplification with respect to roles. The extended original version is fine if you work with this every day. But if you don't, I believe it's incredibly important to keep it simple. I think it would be a fun exercise to see how short and direct you could make the PCI-DSS.

 

Plain English version:

• Plain English: 7.1.1 – Validate privileges following least privilege rule are documented.
• Plain English: 7.1.2 – Validate privileges are appropriate with management.
• plain English: 7.1.3 – Validate process exists whereby users are correctly assigned.
• Plain English: 7.1.4 – Validate access approvals are documented.

 Extended playlist:

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.	7.1  Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows: ·    Defining access needs and privilege assignments for each role ·    Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities ·    Assignment of access based on individual personnel’s job classification and function ·    Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.	The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice.
7.1.1  Define access needs for each role, including: ·    System components and data resources that each role needs to access for their job function ·    Level of privilege required (for example, user, administrator, etc.) for accessing resources.	7.1.1  Select a sample of roles and verify access needs for each role are defined and include: ·    System components and data resources that each role needs to access for their job function ·    Identification of privilege necessary for each role to perform their job function.	In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly.
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.	7.1.2.a  Interview personnel responsible for assigning access to verify that access to privileged user IDs is: ·    Assigned only to roles that specifically require such privileged access ·    Restricted to least privileges necessary to perform job responsibilities.	When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.

	7.1.2.b   Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are: ·    Necessary for that individual’s job function ·    Restricted to least privileges necessary to perform job responsibilities.	Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID.
7.1.3 Assign access based on individual personnel’s job classification and function.	7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.	Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant individuals access according to their job classification and function by using the already-created roles.
7.1.4 Require documented approval by authorized parties specifying required privileges.	7.1.4  Select a sample of user IDs and compare with documented approvals to verify that: ·    Documented approval exists for the assigned privileges ·    The approval was by authorized parties ·    That specified privileges match the roles assigned to the individual.	Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.