Tom Olzak

Posts Tagged ‘risk’

Shadow IT: Treat the cause, not the symptom

In Application Security, Business Continuity, Cloud Computing, Critical Infrastructure on July 8, 2015 at 04:00

I just posted an article at Toolbox.com about the business risks associated with shadow IT.  Many organizations see shadow IT as a disease to be cured.  However, as I write in my post, shadow IT is a symptom of a deeper issue.  It is this issue, related to IT remaining stuck in the past, that must be addressed.

Home users create security gaps: Fill them

In Access Controls, Application Security, Business Continuity, Cloud Computing, Computers and Internet, Insider risk, iPad, Mobile Device Security, Network Security, Policies and Processes, Policy-based access control, Risk Management on February 13, 2013 at 20:13

In Phishing attacks target home workers as easy ‘back door’ – Techworld.com, John Dunn writes that users fear becoming targets when working at home.  This should surprise no one.  With the rapid growth of BYOD (bring your own device), organizations struggle to close security gaps as they attempt to meet new business requirements of anywhere/anytime delivery of information and business processes. (See The BYOD Trend.)

Smartphones, tablets, and privately-owned laptops are not adequately controlled in most organizations.  Traditional access controls, especially authorization constraints, fail to mitigate risk sufficiently.  One important change organizations can make is to context- or policy-based access controls.  (See Securing Remote Access).

 

 

Controls: The absolute minimum

In Application Security, Cybercrime, Data Security, Log Management, Network Security, Physical Security, Risk Management, Security Management on February 3, 2013 at 17:07

CSIS Logo (SANS)Lulled into false security by years of being told anti-malware is the best way to protect networks and devices, many network administrators  leave their networks wide open.  Using only anti-malware software a firewall, and an IPS leaves gaping holes in the security controls framework.  Attackers with limited experience can locate and exploit attack vectors with little regard for these venerable controls.  While firewalls and IPS devices help, they were never intended to provide a complete prevention/detection/response solution.

SANS provides an up-to-date list of 20 critical security controls (now at version 4.0).  The downloadable documentation provides guidance on in depth, layered integration of controls necessary to fill gaps left by traditional approaches to minimal security.

The Internet is Broken, Part III: Response

In Application Security, Business Continuity, Disaster Recovery, Hacking, Log Management, malware, NetFlow, Network Security, Policies and Processes, Risk Management, Security Management, SIEM on January 20, 2013 at 23:12

This is the final post in a series about the broken Internet.  In the first, we looked at SIEM.  Last week, we explored the value of NetFlow analysis.  This week, we close with an overview of incident response.

When evaluating risk, I like to use as reference the following formula:

Basic Risk Formula

Basic Risk Formula

Probability of occurrence, broken into threats x vulnerabilities, helps us determine how likely it is that a specific threat might reach our information resources.  Business impact is a measure of the negative affects if a threat is able to exploit a vulnerability.  The product of Probability of Occurrence and Business Impact is mitigated by the reasonable and appropriate use of administrative, technical, and physical controls.  One such control is a documented and practiced incident response plan.

The purpose of incident response is to mitigate business impact when we detect an exploited vulnerability.  The steps in this process are shown in the following graphic.  Following the detection of an incident (using SIEM, NetFlow, or some other monitoring control), the first step is to contain it before it can spread or cause more business impact.  Containment is easier in a segmented network; segments under attack are quickly segregated from the rest of the network and isolated from external attackers.

Response Process

Response Process

Following containment, the nature of the attack is assessed.  Failing to follow this step can result in incorrectly identifying the threat, the threat agent, the attack vector, or the target.  Missing any of these can make the following steps less effective.

Once we understand the who, what, when, where, how, and why of an attack, we can eradicate it.  Eradication often takes the form of applying a patch, running updated anti-malware, or system or network reconfiguration.  When we’re certain the threat agent is neutralized, we recover all business processes.

Business process restoration requires a documented and up-to-date business continuity/disaster recovery plan.  Some incidents might require server rebuilds.  Business impact increases as a factor of the time required to restore business operation.  Without the right documentation, the restoration time can easily exceed the maximum tolerable downtime: the time a process can be down without causing irreparable harm to the business.

Finally, we perform root cause analysis.  This involves two assessments.  One determines what was supposed to happen during incident response, what actually happened, and how can we improve.  The second assessment targets the attack itself.  We must understand what broken control or process allowed the threat agent to get as far as it did into our network.  Both assessments result in an action plan for remediation and improvement.

The Internet is broken.  We must assume that one or more devices on our network is compromised.  Can you detect anomalous behavior and effectively react to it when the inevitable attack happens?

Policies are not enough to protect mobile data…

In Access Controls, Application Security, Content Filtering, Data Leak Prevention, Data Security, Mobile Device Security, Policies and Processes, Policy-based access control, Risk Management, Security Management on December 29, 2012 at 12:27

Policy is not enough.  Ensuring sensitive information is handled in accordance with internal policy and regulatory constraints requires monitoring of all activities associated with it.  In other words, inspect what you expect… continuously.  Further, too much reliance on human behavior is a recipe for security disaster.

This week, we learned that the University of Michigan Health System, via a vendor, lost about 4000 patient records.  The vendor, apparently authorized access, copied patient records from a database to an unencrypted device.  The device, left unattended in a vehicle, was then stolen.  Sound familiar?  It should.  This scenario appeared many times in news articles over the last several years.  While the players differed, the gaps leading to the losses were largely the same.

This set of conditions is growing more common.  They are strengthened with an increasing number of devices filling the role of insecure mobile data storage, as the BYOD (bring your own device) phenomenon continues to complete its hold on business operations.  Managers and business owners who believe they can simply write a policy, train employees, and move on to the next challenge are kidding themselves.

(For a detailed look at how competing interests apply pressure every day to employees trying to do the right thing, see Bruce Schneier’s Liars and Outliers.)

So what can we do to protect ourselves from becoming the topic of yet another subject in an article about mobile data loss?  Plenty.

For traditional access control environments…

First, ensure your policies have teeth.  For example, what are the sanctions for a vendor or employee who fails to follow policy?  Next, implement reasonable and appropriate technical controls to monitor traffic (e.g., IPFIX data) and aggregated logs (i.e., SIEM).  IPFIX, for example, provides near real time information about anomalous data flows: like a vendor copying 4000 records from a database.  Finally, implement a process whereby IPFIX and SIEM alerts prompt an immediate review of who did the copying, what they copied the data to, and whether the target device is in compliance with policies addressing data on the device category into which it falls.  For example, if security sees a data transfer to a mobile device, they should confirm that the device is encrypted and the user authorized to carry the data out of the building…

For policy-based organizations…

As BYOD expands the corporate attack surface, policy-based access controls augment the steps listed above.  By default, do not allow anyone to copy data to a mobile device that does not meet policy requirements for data protection.  Policy-based controls authorize user access based on user role, the device used, the location of the user/device, the data and processes accessed, day of the week and time access is requested, and the device’s compliance with security policy.  All of this is automated, preventing reliance on human behavior to protect data.

(For more information on policy-based access controls (also known as context-based access controls), see Chapter 9: Securing Remote Access. )

Again, policies are not enough.  Without technical controls, they rely on human behavior to protect data.  This is a bad idea.  Instead, implement technical controls as far as is reasonable for your organization, and then monitor for compliance to ensure people, processes, and technology are producing expected security outcomes.

%d bloggers like this: