Risk Management

Good afternoon everybody! I hope your day is going well.

Here are today's Interesting Information Security Bits from around the web.

  1. Verizon has released their 2009 Data Breach report. I haven't read it yet, but below are a few people's first thoughts on the report.
    Verizon Business Security Blog >> Blog Archive >> The 2009 Data Breach Investigations Report
    Tags: ( reports )
  2. Martin's first pass at the PCI specific portions of the Verizon report.
    Network Security Blog >> Verizon Data Breach Investigation: The numbers say PCI IS important
    Tags: ( reports )
  3. David's first take on the Verizon report.
    Initial Thoughts on the 2009 Verizon DBIR << The New School of Information Security
    Tags: ( reports )
  4. Shrdlu's take on the Verizon report.
    Once more into the breach report.
    Tags: ( reports )
  5. Time to patch those Oracle installations.
    Oracle delivers major security patch update - Network World
    Tags: ( oracle patches vulnerability )
  6. Interesting article on a sneaky way to get a linux rootkit into the kernel.
    New Attack Sneaks Rootkits Into Linux Kernel - DarkReading
    Tags: ( linux rootkit )
  7. Some good thoughts on risk management and what it means.
    Ascension Blog >> Musing on Risk
    Tags: ( infosec risk-management )
  8. A Q&A with Johnny Long whose new ihackcharities.org website was unveiled recently.
    Q&A: Johnny Long - Christian, Pirate, Hacker, Ninja - Security
    Tags: ( general )

That's it for today. Have fun!

Subscribe to my RSS Feed if you enjoy these daily Interesting Bits posts.

Kevin

{ 0 comments }

In the last post in our series on FAIR we took a look at the data flow diagram for the system that Oblivia wants us to assess. We also reviewed the definition of threat and quickly figured out we need a way to narrow down which threats we should be most concerned about.

FAIR uses the concepts of threat communities and threat characteristics to help us group together like threat agents and help us determine the probability of that threat affecting us. A threat agent being an individual person or instance in a threat population or set of threats.

Let's take a look at these two concepts and see how they can help us.

First, the definition of threat community. From the Introduction to FAIR: Risk Landscape Components:

Subsets of the overall threat agent population that share key characteristics

Basically, we are talking about those characteristics that would define a group of threat agents. The Introduction uses at set of characteristics that could be used to place a threat agent in a community call 'terrorist.' How about the following characteristics?

Motive: Money
Primary intent: Financial gain
Sponsorship: Unofficial
Preferred general target characteristics: Systems where small changes are difficult to find
Preferred specific target characteristics: High traffic/significant impact systems
Preferred targets: Systems and applications
Capability: Significant technology skills
Personal risk tolerance: Medium
Concern for collateral damage: High (need for changes to remain unnoticed)

What could we call the threat community whose agents have these characteristics? I'm going to hate myself for using the term, but cyber criminals seems to work. Individuals who make money by subverting computer systems. This gives us some information about what makes up the community. Now we need some information that can help us determine which communities are worthy of more inspection. That is where threat characteristics come in.

From the Introduction, paraphrased a bit:

There are four primary characteristics we are concerned with in our risk taxonomy:

  • The frequency with which threat agents come into contact with our organizations or assets
  • The probability that threat agents will act against our organizations or assets
  • The probability of threat agent actions being successful in overcoming protective controls
  • The probable nature (type and severity) of impact to our assets

What we are really concerned about from an agent characteristic perspective is, frequency of contact, the likelihood that the agent will act against us, the likelihood that the agent will succeed and the likely type and severity the result of that action to our assets.

A situation where the agent is rarely in contact, is unlikely to actually attack us and even more unlikely to succeed if they do and, finally, the impact if they are successful will be insignificant is much different that one where the agent is in constant contact, is very likely to act against us, is skillful enough to succeed and probably going to result in severe impacts to our assets.

Understanding the different communities and the significant characteristics mentioned above can help us a great deal in managing risk. They help us have a much more concrete estimate of the probability of something untoward happening to us as the result of a threat agent acting against us.

In our next installment we will take one more quick look at a few characteristics related to assets. We will then dive into risk factoring in the next few posts.

As always, I am really interested in your thoughts. I read and take to heart every comment that is left and email received, so please join the conversation!

-Kevin

{ 0 comments }

Good afternoon everybody! I hope your day is going well.

Here are today's Interesting Information Security Bits from around the web.

  1. Some good tips in this article about dealing with unkowns when performing a risk assessment.
    Assuming the breach: Mapping the Unknown Unknowns
    Tags: ( risk-management )
  2. Matt has a good article up that takes a quick look at what the power companies are doing.
    SMRT Grid : Liquidmatrix Security Digest
    Tags: ( power scada )
  3. Xavier talks about a nifty too called SEAT (Search Engine Assessment Tool.) Definitely worth taking a look at.
    /dev/random >> Blog Archive >> Introduction to SEAT
    Tags: ( tools seat )
  4. Chris posts part two of his rebuttal to Stuart King. Good stuff in there.
    Stuart King - Information Security Annoyances - Response 2 << Risktical Ramblings
    Tags: ( risk-modeling )
  5. Dave offers some suggestions on things we should be doing during these difficult times where layoff are becoming more and more prevalent.
    ShackF00 >> Security's Role in Downsizing
    Tags: ( general )

That's it for today. Have fun!

Subscribe to my RSS Feed if you enjoy these daily Interesting Bits posts.

Kevin

{ 0 comments }

In the last post in our series, we spent some time looking at the definition of asset. In the post previous to that, we described the system we are assessing and a presented a diagram that shows the system and its architecture.

In this post, we are going to start the discussion about threats, but first, a little more information about our scenario.

Phil, in a comment on the last post in this series, said the following.

I suggest that you create a data flow diagram (DFD) and then map out how the data flows.

After saying a) I don't know how and b) we don't need one (not in those exact words :)), I got to thinking about it a bit more and decided he was right. A data flow diagram will be helpful. So a quick study of DFDs later, here is my feeble attempt at providing one for us to use.

Oblivia Tax Rate System Data Flow Diagram (DFD)

Oblivia Tax Rate System Data Flow Diagram (DFD)

You will probably quickly see where we will be focusing our time during our assessment.

Anyway, let's talk about threats. First, from the Introduction to FAIR: Risk Landscape Components:

As I [Jack Jones] mentioned in the Bald Tire section, threats are anything (e.g., object, substance, human, etc.) that are capable of acting against an asset in a manner that can result in harm. A tornado is a threat, as is a flood, as is a hacker. The key consideration is that threats apply the force (water, wind, exploit code, etc.) against an asset that can cause a loss event to occur.

Fairly straight forward. Basically, we are looking for those things that, when they apply force against our asset, can cause damage or loss. Well, even in the simplistic scenario we are looking at, that list is as long as my arm. If that's the case, how to know which threats we should focus on?

Funny you should ask. Jack goes on to talk about threat communities, "Subsets of the overall threat agent population that share key characteristics [or traits]", and threat characteristics which are used to profile threat communities. We will take a deeper look at both in the next post of this series.

As always, I am really interested in your thoughts. I read and take to heart every one that is left, so please join the conversation!

-Kevin

Reblog this post [with Zemanta]

{ 3 comments }

Exploring F.A.I.R – Assets Redux

by kriggins on February 26, 2009

in fair, Risk Management

So, to revisit the post which sparked the last few, let's talk about assets. Before we get started though, just a reminder that all the posts in this series can be found on this page.

And now, on with the show. We have described the organization for which we are performing the assessment. We have also described, to a certain extent, the architecture of the system involved.

Again, we are going to take things in a little different order than presented in the Introduction to FAIR. The first thing we are going to look at is asset. From the introduction:

Any data, device, or other component of the environment that supports information-related activities, which can be illicitly accessed, used, disclosed, altered, destroyed, and/or stolen, resulting in loss.

With this definition in mind, why don't we make a list of the assets we might be concerned about.

  • Bandwidth
  • Hardware (Servers, routers, switches, firewalls, etc.)
  • Services (Web services and database services)
  • Information (Tax code and tax rates)

The bandwidth is an asset because evil doers on the internet need a way to spread their evil. They would much prefer to use our bandwidth than pay for their own.

The hardware is an asset because someone might want to steal it or run their own software on it.

The services provided are an asset for similar reasons. The evil doers need places to put the stuff they want to spread or a place to stash the stuff they have already taken elsewhere.

The information is an asset because...well...it's why the rest of the stuff is there in the first place ๐Ÿ™‚ Seriously, information is always an asset. As discussed in the first post on assets, it likely doesn't matter if the information is classified as public or not. The integrity and availability of that public information can be very important.

For instance, in our case, the information defines how much money a company will have to pay in taxes. If it is modified or deleted, it can have a serious effect on the revenue of the state.

Ideally, we would perform a risk analysis for each asset "class" above and incorporate all the results into our risk assessment. For our purposes though, we are going to concentrate on just one, the information.

In the next post in this series we will take a look at threats and threat agents.

As always, please let me know your thoughts in the comments.

-Kevin

Image courtesy of tao_zyn.
Reblog this post [with Zemanta]

{ 5 comments }

In the last post of the series we took a look at the organization we are helping out with our assessment. We also were given their Loss Magnitude Table. That table gives us a good idea of their risk tolerance.

Today we are going to look at the architecture of the system that hosts Oblivia's tax code and tax rate tables.

As indicated before, Oblivia is does not have a very mature technology infrastructure. However, they have been given some good advice about the need for firewalls and to only allow needed ports and such. Below is a diagram of their public facing web infrastructure.

Oblivia Internet Facing Network Architecture

The system configurations are as follows:

Web Server:

  • Operating System: A Very Fine OS (fully patched)
  • HTTPD Software: A Very Fine Web Server (fully patched)
  • CMS: An internally developed application. A penetration test was recently performed and several XSS issues were uncovered along with one SQL injection problemย  (import bits of information for later.)

Database Server:

  • Operating System: A Very Fine OS (fully patched)
  • Database Server: A Very Fine DB Server (fully patched)

As you can see, keeping systems appropriately patched has been another good bit of advice given and taken to heart. We will definitely be visiting some of the traffic allowed as we progress. ๐Ÿ™‚

On final note, there is no remote access solution in place, but those responsible for the systems sometimes need to be able to work on them from remote locations, i.e. home. You can probable tell how they are doing from the ports allowed through the firewalls.

In our next post, we will again look at assets again. As always, fell free to chime in on the comments if you have something to say or I goofed again ๐Ÿ™‚

-Kevin

PS - For those interested, the diagram above was created with Gliffy. It is a really nifty free on-line diagramming tool.

{ 0 comments }

Exploring FAIR – What’s an Asset?

by kriggins on January 30, 2009

in Risk Management

In this post we are going to start exploring the terminology of FAIR. It makes sense to me that we explore FAIR through the use of an example scenario, much like the FAIR Introduction (link to pdf) does.

We are going to use a web site for our scenario. We will develop the scenario more and more as we go along, but the following are the initial characteristics:

  • The web server is an up-to-date version of Apache.
  • The information stored on the server is public.
  • The web server is exposed to the internet.
  • The bandwidth available is significant.

We are going to take things in a little different order than presented in the Introduction to FAIR. The first thing we are going to look at is asset. From the introduction:

Any data, device, or other component of the environment that supports information-related activities, which can be illicitly accessed, used, disclosed, altered, destroyed, and/or stolen, resulting in loss.

With this definition in mind, what asset or assets are present that we need to be worried about?

Is the information in this case an asset? No, because we've classified the information as public. Three things come to mind as assets with the information we have so far, the physical hardware Apache is running on, the Apache web server itself and the available bandwidth.

The hardware is an asset because someone might want to steal it or run their own software on it. The web server is an asset because someone might want to use it for their own purposes. The bandwidth is an asset because, again, someone may want to use that bandwidth, that we pay for, for their own purposes.

Pretty basic and straightforward. Next time we will look at "What's a threat?"

As always, the comments are open. Feel free to share your thoughts.

-Kevin

Image courtesy of tao_zyn.
Reblog this post [with Zemanta]

{ 6 comments }

Good afternoon everybody! I hope your day is going well.

Here are today's Interesting Information Security Bits from around the web.

  1. I agree completely with George on this one. Arguing that PCI DSS is a failure because two organization that were compliant experienced breaches is like saying door locks are a failure because somebody broke into your house.
    The Death of PCI DSS? Don't Be Silly - Security Blog - InformationWeek
    Tags: ( pci breach )
  2. This is a good article to pass on to your family and friends. The tips are very good and will raise the awareness level of any who reads the article.
    12 tips for managing your information footprint
    Tags: ( privacy )
  3. The next in the series.
    The Business Justification For Data Security: Data Valuation | securosis.com
    Tags: ( risk-management )
  4. The third post in the series.
    The Business Justification for Data Security: Information Valuation Examples | securosis.com
    Tags: ( risk-management )

That's it for today. Have fun!

Subscribe to my RSS Feed if you enjoy these daily Interesting Bits posts.

Kevin

Reblog this post [with Zemanta]

{ 1 comment }

Every business has information of one kind or another. That information is most often processed, transmitted and stored using information technology. While that information is being processed, transmitted and stored, it is exposed to a certain level of risk, even if it never leaves the confines of the business's building.

As information security professionals, we are tasked with ensuring that our business's information is protected. To do so, we need to implement processes, procedures, and controls that reduce risk to an acceptable level. Unfortunately, our companies do not have endless resources, either in terms of man power or money. That means we need a method of determining how much risk exists and what is an appropriate level of resources, if any,ย  to expend to address that risk.

Enter Factor Analysis of Information Risk (FAIR.) FAIR is the brain child of Jack J. Jones, CISSP, CISM, CISA of Risk Management Insight, LLC and has been released under the Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.

So what is FAIR? From the Wiki:

Factor Analysis of Information Risk (FAIR) provides a framework for understanding, analyzing, and measuring information risk. The outcomes are more cost-effective information risk management, greater credibility for the information security profession, and a foundation from which to develop a scientific approach to information risk management.

Together, over what will likely be a fairly long series of posts, we are going to explore FAIR. This will help me internalize the concepts and hopefully you will find it an interesting ride too.

I have already pointed to the Wiki above. There are also a few other sources of information and tools available if you want to read ahead.

The Basic Risk Assessment Guide lives here. Note: direct link to the pdf.

Alex Hutton frequently writes about FAIR on his blog.

Chris Hayes has done some great work on his blog about FAIR too.

Next we will start digging into the terminology used in FAIR. As always, comments are open. Feel free to let me know what you think.

-Kevin


{ 3 comments }