1. Going 15 mph over the speed limit.
2. Using a public wireless internet connection at the airport.
3. Using a third party for payment services.

If you were to ask your neighbor how they would rate them, would it be the same?  Go ahead and ask them, I’ll wait.  For those not asking, do you think they would be the same?  Probably not.  Assigning a risk label to an event is too subjective.  It’s based upon the person’s experience, profession, and situational awareness.  How one labels risk most likely will not be the same as someone else.  This is mostly due to the lack of comparable impacts.

Assigning impact consistently is manageable with guidance.  These may include factors such as:

• Fiscal costs to replace/fix.
• Employee hours needed (will you have to outsource?)
• Damage to reputation (usually more for service providers)
• Harm to individuals (employees and / or patients)?

Each of these factors and the threshold from one to the next is organization specific.  $10,000 in replacement systems for one company may be fairly significant while for another it may be the budget for the annual holiday party.  Establishing the different thresholds for each of your risk layers will make this a repeatable process.  It’s an easier process than most think; just go through the possibilities for each.  If this would cost our organization $__________ it would be bad, $____________ is really bad, and $_______________ is “I’m packing up my office right now.”  Just keep doing that on all your impact decision factors.

Creating a matrix will help quickly assign such risk impacts and also ensure that the right people are involved the process.  That’s correct: assigning risks, the impact, and the likelihood, shouldn’t be a one person job; there are too many factors for one person to know.  Healthcare is a great example.  IT can determine how much it would cost to replace/fix a server but IT most likely will not be able to properly gauge organizational reputation damage and the potential harm to patients.

Having more people with different roles also brings more situation awareness (i.e., threat likelihood) to the risk assignment process.  They may be aware of additional controls which could lessen the change of the risk being realized. The more the situational awareness is raised allows your company to assess risks with greater understanding and accuracy. For example, would your risks you assigned to the examples above change with the following?

1. Going 15 mph over the speed limit in a school zone.
2. Using a public wireless internet connection at the airport after Defcon.
3. Using a third party for payment services that continues to suffer data breaches.

All of the aspects above increase the maturity level of risk assignments used in Risk Management programs, audits, and everyday operations. It helps everyone within the organization speak the same language and ensure that we compare apples to apples.  When everyone is on the same plane and knows how the risks are being assigned there tends to also be less resistance to risk reducing initiatives. This level of organizational “buy-in” is crucial for those projects that have a large impact radius and cross many departmental boundaries.

So how does this all start?  The easiest is to integrate this process as part of your Risk Management program and during each Risk Assessment. Use the same processes for your internal audits and have external companies either use your process or provide enough information to allow your group to rate findings again internally. Document the process and the various factors and make sure all involved know what they are. This will lead you down some interesting conversations, but stick to it!

Having an established and consistent process turns the arbitrary into the meaningful.

In these talks, most time was spent noting that Cloud environments are shared and, in executing a pentest against such an environment, there was a substantially higher risk of impacting other (non-target) environments.  For example, if testing a web application hosted by a software-as-a-service (SaaS) provider, one could run the risk of knocking over the application and/or the shared infrastructure and causing a denial of service condition for other customers of the provider in addition to the target application instance.  This is certainly a fair concern but it is hardly a revelation.  In fact, if your pentesting company doesn’t have a comprehensive risk management plan in place that aims to minimize this sort of event, I recommend looking elsewhere.  Also, the speakers noted that getting permission from the Cloud provider to execute such a test can be extremely difficult.  This is no doubt due to the previously mentioned risks, as well as the fact that service providers are typically rather hesitant to reveal their true security posture to their customers.  (It should be noted that some Cloud providers, such as Amazon, have very reasonable policies on the use of security assessment tools and services.)

In any case, what I really wanted to know was this: is there anything fundamentally different about testing against a Cloud-based environment as compared with testing against a more traditional environment?

After much discussion with others in the industry, I have concluded that there really isn’t.

Regardless of the scope of testing (e.g., application, system, network), the underlying technology is basically the same in either situation.  In a Cloud environment, some of the components may be virtualized or shared but, from a security standpoint, the same controls still apply.  A set of servers and networking devices virtualized and hosted in the Cloud can be tested in the same manner as a physical infrastructure.  Sure, there may be a desire to also test the underlying virtualization technology but, with regard to the assets (e.g., databases, web servers, domain controllers), there is no difference.  Testing the virtualization and infrastructure platforms (e.g., Amazon Web Services, vBlock, OpenStack) is also no different; these are simply servers, devices, and applications with network-facing services and interfaces.  All of these systems and devices, whether virtual or not, require patching, strong configuration, and secure code.

In the end, it seems that penetration testing against Cloud environments is not fundamentally different from testing more conventional environments.  The same controls need to exist and these controls can be omitted or misapplied, thereby creating vulnerabilities.  Without a doubt, there are additional components that may need to be considered and tested.  Yet, at the end of the day, the same tried and true application, system, and network testing methodologies can be used to test in the Cloud.

Without getting too far into the technical aspects of the paper, the researchers found that numbers used in the creation of the keys weren’t so random after all.  This culminated in critical parts of the algorithm being similar to another key.  Thus the keys were the same.

What does this mean for you and your organization?  Time to check your encryption settings and certificates.  If you outsource this as part of your e-commerce solution, have the vendor validate their settings.  If you use RSA keys you might consider changing them, of course this isn’t something that most organizations can/will do with minimal impact.  One of the big questions I foresee is if this will affect your PCI Compliance?  At this time no.

While many recognize that risk posed by the redundant keys found by the researchers is significantly less than it might otherwise be, you most likely will be safe.  However this is something to keep tabs on.  If further research continues to find issues with how the prime numbers are generated within the methods, it may be time to start the switch.

Overall, it’s important to remember that if you use the RSA keys, the sky isn’t falling all around you, just 0.2% of it is.

Fundamentally, the concept of a risk assessment is straightforward: identify the risks to your organization (within some defined scope) and determine how to treat those risks.  The devil, of course, is in the details.  There are a number of formal risk assessment methodologies that can be followed, such as NIST SP 800-30, OCTAVE, and the risk management framework defined in ISO/IEC 27005 and it makes sense for mature organizations to implement one of these methodologies.  Additionally, risk assessments at larger companies will often feed into an Audit Plan.  If you’re responsible for conducting a risk assessment for a smaller or less mature company, though, the thought of performing and documenting a risk assessment may leave you scratching your head.

The first step in any risk assessment is to identify the scope of the assessment, be they departments, business process, systems and applications, or devices.  For example, a risk assessment at a financial services company may focus on a particular business unit and the regulated data and systems used by that group.  Next, the threats to these workflows, systems, or assets should be identified; threats can include both intentional and unintentional acts and may be electronic or physical.  Hackers, power outages, and hurricanes are all possible threats to consider.  In some cases, controls for addressing the vulnerabilities associated with these threats may already exist so they should be taken into account.  Quantifying the impact to the organization should one of these threats be realized is the next step in the risk assessment process.  In many cases, impact is measured in financial terms because dollars are pretty tangible to most people but financial impact is not always the only concern.  Finally, this potential impact should be combined with the likelihood that such an event will occur in order to quantify the overall risk.  Some organizations will be satisfied with quantifying risk as high, medium, or low, but a more granular approach can certainly be taken.

When it comes to treating risks, the options are fairly well understood.  An organization can apply appropriate controls to reduce the risk, avoid the risk by altering business processes or technology such that the risk no longer applies, share the risk with a third party through contracts (including insurance), or knowingly and objectively determine to accept the risk.

At the conclusion of all of the risk assessment and treatment activities, some sort of documentation needs to be created.  This doesn’t need to be a lengthy formal report but, whatever the form, it should summarize the scope of the assessment, the identified threats and risks, and the risk treatment decisions.  Results from the Audit Plans can also assist in this documentation process.

Most organizations already assess and treat risks operationally and wrapping a formal process around the analysis and decision-making involved should not be overwhelming.  Of course, different organizations may need more rigor in their risk assessment process based on internal or external requirements and this is not meant to be a one-size-fits-all guide to risk assessment.  Rather, the approach outlined above should provide some guidance, and hopefully inspire some confidence to security stakeholders who are just starting down the road of formal risk management.

For those that suffer through this during your Policy Update sessions, there a few ways to break out of this cycle:

1. Establish a Grace Period when policies are updated. This is usually established within a policy about policies (feel like the definition of recursion?). Some organizations will issue policies with a Published Date and next to it an Effective Date. This reminds readers about the Grace Period while reinforcing the expectation that compliance is required in the near future.

a. Pros: Staff can work towards compliance by the established deadline without the label of ‘Non-Compliant.’ Project plans, budgets, and resources can be lined up to tackle the changes.

b. Cons: Effective dates may be too soon for some large changes, but having different effective dates for some projects but not everything leads to confusion. If the timeframes don’t run in parallel with budget cycles then there may not be enough available funds for changes that require fiscal resources. The other concern is that during the Grace Period, there may be the perception of having two active policies which may lead to some confusion.

2. Establish, or merge with an existing, Exception Process for non-compliant areas when the policies are published. If there are areas of non-compliance when the policies are updated then an exception must be immediately requested for a temporary acceptance. Part of this exception process will be to establish a plan of attack for reaching compliance.

a. Pros: The exceptions help to prioritize the identified non-compliant areas which may make it easier to see the total cost of compliance; this method is easier for organizations that have strong Project Management departments.

b. Cons: It may be overwhelming for the team reviewing all the exception requests. Especially for those that can’t assess all associative risks (such as business versus IT risks). There will also be overhead to track all the exceptions and the deadlines. Continual exception requests will have to be managed appropriately.

3. Establish a Hybrid Approach. This method takes a little from each above with tweaks to meet the needs of your organization. For example, establishing a short Grace Period for new / updated policies and anything that will need longer must be identified immediately and go through the Exception Process.

a. Pros: A sooner effective date will meet with regulatory requirements quicker. There may be a smaller Exception handling team yet the organization still receives the benefit of using Project Management to handle the outliers.

b. Cons: It is easy for this method to slide more into the Exception Process without the constant enforcement of the effective dates. A shorter Grace Period may result in an unexpected amount of Exception requests depending upon the policy.

Regardless of the method, the most successful implementations negate the Cons listed above with two major factors: (1) Management’s full support (which includes enforcement) and (2) communication.  Lack of those two elements often will leave you with a feeling that the wheels are spinning, but you aren’t moving.  Of course funding, or the lack thereof, is like a car with no gas – it’s only great if you want to go where you already are. 

The corporate culture may also dictate which approach is more likely to succeed.  Proactive organizations usually try for the Grace Period method while reactive organizations are better suited for the Exception Method.  This isn’t a slight against one or another, but in those instances the culture has established tools and workflows designed for one or the other. 

For example; reactive cultures are usually found in healthcare, especially hospitals, since that’s the name of the game: reacting to the events around them.  Financial institutions tend to be more proactive due to many of the existing regulations (SOX, GLBA, etc.).   It’s not to say that you won’t find Proactive healthcare institutions (which some are trying to be) or reactive financial organizations. 

Hopefully adoption of one of the above methods helps during your next Policy Update cycle so you can make changes happen; as behaviors, controls, and other requirements usually won’t change just because they can. 

“Catch-22 says they have a right to do anything we can’t stop them from doing.

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.

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.

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.

In many discussions about Insider Threats I’ve referred to the San Francisco IT Administrator charged with holding the city’s network hostage.  In this particular case he didn’t give the administrative credentials back to his employer but kept the systems operational.  It was a good example but is now a bit dated (2008) but it was only a matter of time before another one emerged.

With a roar, it did.  An IT Administrator has recently pleaded guilty to crippling his former employer’s network.  Now some have dubbed this a “hacking spree” but I would like to differentiate this as not a hack, but an individual that had elevated privileges that became so disgruntled that he lashed out.  When he did so, he didn’t use specialized hacking tools or techniques, instead he used a common administrative tool to delete critical IT systems causing in excess of $800,000 in damages according to court documents. 

What makes this example worse is that this individual resigned before the attack, but the organization kept him on as a consultant “due to this extensive knowledge of the company’s network.”  He performed his attacks with valid user credentials and common support tools. 

Why am I trying to draw such a distinction whether this is hacking or not?  When discussing risks as either part of your normal risk assessments, Risk Management Program, etc. I think it is important to draw the distinction as it relates to policies and implementable controls.  There is usually a lot of effort put into place to protect against malicious and unauthorized attacks (i.e., hacking) compared to disgruntled individuals with elevated privileges.  Malicious?  Yes.  Unauthorized?  No.  That’s the scary part and the one that needs to be addressed by each and every organization. The take away here is to ensure that segregation of duties is followed so not one person has keys to the kingdom and disgruntled employees are not retained where they can cause extensive damage to the organization.

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.

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.