NetSPI Imformation Security Consulting
NetSPI Blog

POSTS BY RYAN WAKEHAM

Why I Hate The Cloud

| Wednesday, October 26th, 2011

The Cloud is one of the “new big things” in IT and security and I hate it.  To be clear, I don’t actually hate the concept of The Cloud (I’ll get to that in a minute) but, rather, I hate the term.

According to Wikipedia, cloud computing is “the delivery of computing as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a utility (like the electricity grid) over a network (typically the Internet).”  What this pretty much amounts to is outsourcing.  There are a lot of reasons that people “move to The Cloud” and I’m not really going to dive into them all; suffice it to say that it comes down to cost and the efficiencies that Cloud providers are able to leverage typically allow them to operate at lower cost than most organizations would spend accomplishing the same task.  Who doesn’t like better efficiency and cost savings?

But what is cloud computing really?  Some people use the term to refer to infrastructure as a service (IaaS), or an environment that is sitting on someone else’s servers; typically, the environment is virtualized and dynamically scalable (remember that whole efficiency / cost savings thing).  A good example of an IaaS provider is Amazon Web Services.  Software as a service (SaaS) is also a common and not particularly new concept that leverages the concept of The Cloud.  There are literally thousands of SaaS providers but some of the better known ones are Salesforce.com and Google Apps.  Platform as a Service (PaaS) is less well-known term but the concept is familiar: PaaS providers the building blocks for hosted custom applications.  Often, PaaS and IaaS solutions are integrated.  An example of a PaaS provider is Force.com.  The Private Cloud is also generating some buzz with packages such as Vblock, and OpenStack; really, these are just virtualized infrastructures.

I’m currently at the Hacker Halted 2011 conference in Miami (a fledgling but well-organized event) and one of the presentation tracks is dedicated to The Cloud.  There have been some good presentations but both presenters and audience members have struggled a bit with defining what they mean by The Cloud.  One presenter stated that “if virtualization is involved, it is usually considered to be a cloud.”  If we’re already calling it virtualization, why do we also need to call it The Cloud? To be fair, The Cloud is an appropriate term in some ways because it represents the nebulous boundaries of modern IT environments.  No longer is an organization’s IT infrastructure bound by company-owned walls; it is an amalgamation of company and third party managed party services, networks, and applications.  Even so, The Cloud is too much of a vague marketing term for my taste.  Rather than lumping every Internet-based service together in a generic bucket, we should say what we really mean.  Achieving good security and compliance is already difficult within traditional corporate environments.  Let’s at least all agree to speak the same language.

Permalink | Email the Author | No Comments

Tags: , , , ,

Mobile Devices in Corporate Environments

| Wednesday, October 12th, 2011

Mobile computing technology is hardly a recent phenomenon but, with the influx of mobile devices such as smartphones and tablet computers into the workplace, the specter of malicious activity being initiated by or through these devices looms large.  However, generally speaking, an information security toolkit that includes appropriate controls for addressing threats presented by corporate laptops should also be able to deal with company-owned smartphones.

 

My recommendations for mitigating the risk of mobile devices in your environment include the following:

  • Establish a Strong Policy
  • Educate Users
  • Implement Local Access Controls
  • Minimize the Mobile Footprint
  • Restrict Connectivity
  • Restrict Web Application Functionality
  • Assess Mobile Applications
  • Encrypt, Encrypt, Encrypt
  • Enable Remote Wipe Functionality
  • Implement a Mobile Device Management System
  • Provide Support for Employee-Owned Devices 

For more detailed information, take a look at the white paper that I just put together on the subject: Dealing with Mobile Devices in a Corporate Environment.

Permalink | Email the Author | No Comments

Tags:

Do You Know Where Your Data Is?

| Tuesday, October 4th, 2011

When it comes to application of security controls, many organizations have gotten pretty good at selecting and implementing technologies that create defense-in-depth.  Network segmentation, authorization and access control, and vulnerability management are all fairly well understood and generally practiced by companies these days.  However, many organizations are still at risk because they can’t answer a simple question: where is sensitive data?  It should go without saying but if a company can’t identify the locations where sensitive data is stored, processed, or transmitted, it will have a pretty hard time implementing controls that will effectively protect that data.

Two effective methods for identifying sensitive data repositories and transmission channels are data flow mapping and automated data discovery.  A comprehensive and accurate approach will include both.  Note, of course, that both methods assume that you have already defined what types of data are considered sensitive; if this is not the case, you will need to go through a data classification exercise and create a data classification policy.

Data flow mapping is exactly what it sounds like: a table-top exercise to identify how sensitive data enters the organization and where it goes once inside.  Data flow mapping is typically pretty interview-centric, as you will need to really dig into the business processes that manipulate, move, and store sensitive data.  Depending on the size and complexity of your organization, data flow mapping could either be very straightforward or extremely complicated.  However, it is the only reliable way to determine the actual path that sensitive data takes through your organization.  As you conduct your interviews, remember that you want to identify all the ways that sensitive data is input into a business process, where it is stored and processed, who handles it and how, and what the outputs are.  Make sure that you get multiple perspectives on individual business processes as validation and also match up the outputs of one process with the inputs of another.  It is not uncommon for employees in one business unit or area to have misunderstandings about other processes; your goal is to piece together the entire puzzle.

Automated data discovery does a poor job of shedding light on the mechanisms that move sensitive data around an organization but it can be very valuable for validating assumptions, identifying exceptions, and helping to reveal the true size of certain data repositories.  There are a number of free and commercial tools that can be used for data discovery (one of the most popular free tools is Cornell University’s Spider tool) but they all aim to accomplish the same objective: provide you with a list of files and repositories that contain data that you have defined as sensitive.  Good places to start your discovery include network shares, databases, portal applications, home drives on both servers and workstations, and email inboxes.  Be aware that most discovery tools will require that you provide or select a regular expression that matches the format of particular data fields.  However, some more advanced commercial tools also provide signature learning features.

Ultimately, your data discovery exercise should result in a much improved understanding of how sensitive data passes through your organization and where it is stored.  The next step is to determine how to apply controls based on where data is stored, processed, and transmitted.  Also, where necessary, business processes may need to be adjusted in order to consolidate data and meet data protection requirements.   While identification of sensitive data is only the first phase in a process that will result in better data security and reduced risk, it is an absolutely critical step if application of security controls is to be effective.

Permalink | Email the Author | No Comments

Tags:

Hacking Twitter for Fun (and Profit?)

| Friday, September 16th, 2011

Just last week, on the eve of the tenth anniversary of the 9/11 attacks, NBC News’ Twitter account was hacked by a group calling itself The Script Kiddies. Posing as NBC News, The Script Kiddies falsely tweeted that an airliner had been hijacked and flown into the Ground Zero site in New York City. This is the second such attack perpetrated by The Script Kiddies, the first being a  July 4 hack of the Fox News Twitter claiming that President Obama had been assassinated. In both cases, the spurious posts were quickly removed by Twitter and the news agencies.

Traditionally, hackers have chosen their targets in order to either profit financially or make a political statement (never mind the advanced persistent threats represented by nation states and powerful criminal organizations); recent publicized attacks demonstrate this. Fame and reputation have always been motivators for hackers but, in recent years, business-savvy blackhats seem to have outnumbered the jesters of the digital underground by a wide margin. Twitter hacks are hardly uncommon and generally seem to be done more for amusement than for any truly nefarious purpose, but they mostly slip by unnoticed aside from a handful of celebrity victims and entertainment reporters. As far as I can tell, the NBC and Fox attacks are no different in terms of motivation, but the side effects are much more serious. Cyber terrorism has been a buzz topic for some time now and, while false news reports may rank relatively low on the impact scale, it is probably only a matter of time before this sort of event occurs specifically in order to incite panic in the general population. That would be a real paradigm shift but I don’t know that we’re there yet. These attacks appear to serve no obvious purpose beyond self-promotion.

Permalink | Email the Author | No Comments

Tags: , , ,

Metrics: Your Security Yardstick – Part 2 – Defining Metrics

| Thursday, September 15th, 2011

After a number of questions on the topic, I have decided to follow up on my earlier security metrics blog with a bit more information regarding metrics development. The diagram below outlines the metrics development process.

Security Metrics Development Process

1. Identify Controls to Measure – This is pretty self-explanatory: which controls do you want to evaluate? In very mature security programs, metrics may be gathered on numerous controls across multiple control areas. However, if you’re just starting out, you likely would not realize significant value from such detailed metrics at this time and would benefit more from monitoring key indicators of security health such as security spending, vulnerability management status, and patch compliance. In general, controls to be evaluated should be mapped from external and internal requirements. In this fashion, the impact of controls on compliance can be determined once metrics become available. Conversely, metrics can be designed to measure controls that target key compliance requirements. For this blog, I will focus on metrics related to vulnerability management.

2. Identify Available Sources of Data – This step is established in order to identify all viable sources of data which may be presented singularly or combined with others to create more comprehensive security metrics. Sources of data for metrics will vary based on what sort of controls are being measured. However, it is important that data sources be reliable and objective. Some examples of metrics that can be gathered from a single source (in this case, a vulnerability management tool) are listed in the table below.

 

Name

Type

Number of systems scanned within a time period

Effort

Number of new vulnerabilities discovered within a time period

Effort

Number of new vulnerabilities remediated within a time period

Result

Number of new systems discovered within a time period

Environment

List of current vulnerabilities w/ages (days)

Result

List of current exploitable vulnerabilities w/ages (days)

Result

Number of OS vulnerabilities

Environment

Number of 3rd party vulnerabilities

Environment

List of configured networks

Effort

Total number of systems discovered / configured

Effort

 

3. Define Security Metrics – Decide which metrics accurately represent a measurement of controls implemented by your organization. Begin by developing low-level metrics and then combine to create high level-metrics that provide deeper insight.

a.Low-Level Metrics

Low-level metrics are measurements of aspects of information security within a single area.Each metric may not be sufficient in conveying a complete picture but may be used in context with different metric types.Each metric should attempt to adhere to the following criteria:

·Consistently Measured

·Inexpensive to gather

·Expressed as a cardinal number or a percentage

·Expressed as a unit of measure

Low-level metrics should be identified to focus on key aspects of the information security program.The goal should be to identify as many measurements as possible without concern for how comprehensive each measurement may be.The following are examples of low-level metrics:

·Hosts not patched (Result)

·Hosts fully patched (Result)

·Number of patches applied (Effort)

·Unapplied patches (Environment)

·Time to apply critical patch (Result)

·Time to apply non-critical patch (Result)

·New patches available (Environment)

·Hours spent patching (Effort)

·Hosts scanned (Effort)

b.High-Level Metrics

High-level metrics should be comprised of multiple low-level metrics in order to provide a comprehensive measure of effectiveness.The following are examples of such metrics:

·Unapplied patch ratio

·Unapplied critical patch trend

·Unapplied non-critical patch trend

·Applied / new patch ratio

·Hosts patched / not patched ratio

4. Collect Baseline Metric Data – A timeframe should be established that is sufficient for creating an initial snapshot, as well as basic trending. It is important that you allow enough time to collect a good baseline sample, as data can easily be skewed as you’re working out little bugs in the collection process.

5. Review Effectiveness of Metrics – Review the baseline data collected and determine whether it is effective in representing the success factors of specific controls. If some metrics fall short of the overall goal, another iteration of the metric development process will be necessary.

6. Publish Security Metrics – Begin publishing security metrics in accordance with pre-defined criteria.

As noted above, well-designed metrics must be objective and be based upon reliable data. However, data sources are not always fully understood when selected and, as a result, metrics may end up being less effective than when they were initially designed.

After metrics have been implemented, a suitable timeframe for collecting baseline data should be permitted. Once this has been done, metrics should be reevaluated in order to determine whether or not they provide the requisite information.Some metrics may fall short in this regard; if this is the case, another iteration of the metric development process will be necessary.

Ultimately, metrics are intended to provide insight into the performance of a security program and its controls. If the chosen metrics do not do this effectively, or answer the questions that your organization is asking, then the metrics must be redesigned prior to being published and used for the purposes of decision making.

Permalink | Email the Author | No Comments

« Older Entries