We’re calling this part II - and it’s being advertised as:

“How to conduct a risk analysis and produce a high impact deliverable to senior management.”

With topics:

• The life-cycle of a quantitative risk analysis
• Key control opportunities against targeted attacks
• Getting senior management to understand the risk posed to the business

I got to do the Q&A backchannel on the last presentation, and there were great questions asked.  I think this presentation will be even more exciting, as it’ll cover both analyst and management considerations.

If you’re a regular reader of the blog, I don’t think you’ll have to have attended the last one for this one to be worth your while.

REPEAT PERFORMANCES OF THE FIRST WEBEX ARE AVAILABLE

We’ve had a some folks who attended the original WebEx ask us to do a “private” performance for just their  infosec group and/or other members of their organization (like audit and ERM).

We’ve been given the OK to do these provided that there are a minimum of 5 attendees.  Leave me a comment to this post if you’re interested (be sure to include your email in the submission - it won’t be made public but we’ll need it to contact you to set this up), or just email me:  alexh -shift2- riskmanagementinsight:dot:com.

And if you missed it the first time, the playback of the first preso is here, and the slides are here.

1. What product(s) & version(s) should I use?
2. How much should I plan to spend?

The simplest answer of course is “it depends”. I’ve seen implementations range from a thousand bucks to over several million. Ideally, your virtualization project needs & goals should drive your product selection. The bells & whistles you chose will determine your spending.

10 Basic questions that will help you determine product & cost:

1. Will your Virtual Infrastructure (VI) host production Virtual Machines (VM)?
2. What servers do you already have that can be used as hosts (32bit, 64bit, Mem, Disk, Network)?
3. Do you have a need for High Availability (HA)?
4. Do you have the need to manage SLA’s on your VMs?
5. What will a typical VM in your VI look like (OS, Disk, Mem, Network, CPU)?
6. What other IT resources do you have that can be used (SAN, NAS, Switches, etc…)?
7. What level of comfort does your existing staff have with the various IT resources?
8. Do you have existing hardware/software support agreements with Vendors you could leverage?
9. What tools do you already own that are “virtualization aware” and what new tools will you need?
10. How many VM’s do you plan to scale to?

Please, please, please, don’t make the mistake of implementing features that you don’t need and over-engineering just because the product lets you do so.

If you plan it right your product & cost, questions will be answered with no unpleasant surprises.

ShareThis

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

1. A very fun read from Patrick Mueller (ex-Neohapsis now turned lawyer): "Facing The Monster: The Labors Of Log Management." I am happy that log management has been finally granted a monster status :-)
2. I am happy to see that one of the "five questions to ask before sending your data in the cloud" is "Will I have access to logging and auditing data?" This is indeed a big deal (well, it will be soon) and you will be hearing more about this. I call this "a case of log ransom," since you might need to pay the ransom to see what is "yours" - the logs
3. Again on leaving [some] logs behind. Remember, the point is not that "collecting all" is a good idea, it is that figuring what to pick is IMPOSSIBLE, while "collecting all" is simply very hard :-)
4. This is hot stuff: "Ten reasons you will be unhappy with your SIM solution" (no, I didn't write it :-), but this is mine)
5. Why HA for log management from our star engineer. Those thinking about the reliability of their logging systems should read it.
6. Fun info on web server log analysis for different purposes.
7. "Why Logs and Logging Matters - Part 1" and "Why Logs Matter - Part 2, A Letter" present really good intro logging for compliance and other purposes (even specifically saying "what you do with the logs that matters.")
8. "Smart Business Leaders Support Effective Log Management Practices and Necessary Resources" from Rebecca Herold is a nice basic piece, especially for those outside the circle of logging literati.
9. More from Sanford on logging standards: "Drawing Lines", an awesome post indeed.
10. A MUST read on SIEM and log management from Greg Shipley (I promise this is a coincidence! :-)) In this piece, Mr Neohapsis drop kicks more than a few "latest generation" SIEM tools. Guess which product review mentions "pain" 3 times on one page :-)
11. Finally, this is also worth a read: "Ode to Log Management" where Mr Baum laments logs being pigeonholed in to "another IT management tool" silo despite their broad relevance. He is right - but focusing on one use case after another works...
    

Enjoy!

The various components (sub functions) of security organization should align with the business objectives of the IT and the whole organization. There needs to be a cohesive security strategy in order to align the various comoponents. One good way of understanding the business objective is why is the business parting with money for deploying a specific security component. Why is business giving me money for Compliance? Why is business giving me money to implement IDP? Constitutive questions such as these will help you to understand the fundamental concerns for the business and based on these we can come up with a strategy suitably aligned with the business.

One good example is the area of compliance. Attempting to make each every units of your business complaint with certain standards/legal regulations and so on would be a tall order. First define the scope, draw a circle around the units that need to be compliant, then come up with a strategy to make it compliant by formulating your objective - derived from the business objective of why the business gave you money.

Any security implementation effort should have a well defined focus (scope), business objective and strategy to bind the various components cohesively that aligns with the ultimate business objective. By this business will view security organization with dignity else security organization will end up being a spoke in the wheel of business.

In the past, I was involved in discussion about the ROI of information security and security is insurance and so on. After eating the forbidden apple from the tree of paradise, I realize security has neither ROI nor akin to insurance. Information security is way of doing business with due care. Security is way of enhancing the trust of a business among customers and thus enhancing the identity (or brand image of the company). Few years down the line people won't even question why you do security, it will become a part of  your background conversation. Nobody questions why we buy hybrid vehicles anymore right?

If components of security function is not cohesively aligned with business objective it is spoke in the wheel of business else it is a brand enhancer of business.

We heard a lot about cloud computing at the Gartner show this week. You can read a bit about their take on it here. While we’ve been musing on the different ways we monitor cloud computing resources, Hyperic is already announcing their solution to monitor Amazon’s cloud computing availability. Hyperic believes that “making use of cloud resources would be more popular if the customers had an independent means to monitor cloud services.” They plan to offer the monitoring service to other cloud companies this year. However, John Willis questions the hype of Hyperic.

Here are some interesting NetFlow use stats from our friends at Network Instruments. In a survey they did a few months ago, only 23% of respondents used NetFlow to monitor network performance; 60% didn’t use flow tech and 17% weren’t sure they had anything for it. I have to say we are asked at every Interop show we do if we support NetFlow so the numbers are slightly surprising but useful.

Kuala Lumpur is bullish on Sun’s virtualization strategy.

Just like at the Gartner show, one of the tracks at the Burton Group’s conference this week is on virtualization. This post on the Data Center Strategies blog covers Day 1 with some interesting notes on where virtualization needs to go, from clarity around software licensing and support to the use of raw storage (connecting VMs directly to LUNs) to improve VM performance, provide better integration with storage and data management solutions, and prevent vendor lock-in.

ShareThis

Blogger: Randall Gamby

Across the different security technology presentations given this week at Catalyst, one common theme has been the important role of policy. As people hear about new and better technologies and how they can be integrated into their existing infrastructures, they should take the time to examine their policies to make sure they keep up with the solutions being considered.  Questions to ask:

• When did we review our policies last?
• Do we have not enough or too many?
• Will they still be valid?
• Are there other influencers on them?

But while changes will most likely be needed for many current policies, a question that often isn’t asked is, “Are they enforceable?”  As enterprises create policies based upon what users “should do,” can the security team validate that they “did do” what was asked?  For example, a common policy is, “All sensitive data at rest must be encrypted.”  So this means you must encrypt your Active Directory, your e-mail storage, every production database, yes? That's probably not happening.  So if the enterprise has no way to implement the policy, then it ultimately is not a valid policy and needs to either be modified or the enterprise needs money, resources and time to conform to the policy. 

The social effect on the user population also needs to be considered.  Essentially, the enterprise is teaching users that they don’t have to conform to this policy, so maybe they don’t have to be conformant to others on the books.  Not a good lesson to teach them.

So as the Catalyst attendees go back with “dreams of technology sugar plums dancing in their heads” don’t forget that good governance with valid processes should be skipping around the edge.

Blogger: Randall Gamby

Across the different security technology presentations given this week at Catalyst, one common theme has been the important role of policy. As people hear about new and better technologies and how they can be integrated into their existing infrastructures, they should take the time to examine their policies to make sure they keep up with the solutions being considered.  Questions to ask:

• When did we review our policies last?
• Do we have not enough or too many?
• Will they still be valid?
• Are there other influencers on them?

But while changes will most likely be needed for many current policies, a question that often isn???t asked is, ???Are they enforceable????  As enterprises create policies based upon what users ???should do,??? can the security team validate that they ???did do??? what was asked?  For example, a common policy is, ???All sensitive data at rest must be encrypted.???  So this means you must encrypt your Active Directory, your e-mail storage, every production database, yes? That's probably not happening.  So if the enterprise has no way to implement the policy, then it ultimately is not a valid policy and needs to either be modified or the enterprise needs money, resources and time to conform to the policy. 

The social effect on the user population also needs to be considered.  Essentially, the enterprise is teaching users that they don???t have to conform to this policy, so maybe they don???t have to be conformant to others on the books.  Not a good lesson to teach them.

So as the Catalyst attendees go back with ???dreams of technology sugar plums dancing in their heads??? don???t forget that good governance with valid processes should be skipping around the edge.