Month: March 2007

Perspectives on Obtaining Management Support

March 22, 2007 — Leave a comment

Looking to obtain management support!  It’s not always easy.  Many organizations security officers are always looking to obtain more management support and funding for their programs.  This can be a difficult task, so what I have done below is list a few perspectives that work within different organizations.  

 

Compliance – The number one way to get management support is from compliance regulations such as GLBA, HIPAA, SOX, and PCI.  If management doesn’t already know what they need to do then educate them and you will get support and funding to implement parts of the program.

 

Third Party Review – This can be as simple as doing a risk assessment or by hiring skilled ethical hackers to show weakness in the organizations information systems.  The main point is that management tends to listen more to third parties then internal security staff.  Sometimes there is nothing new that comes out of these assessments that the CISO/CSO doesn’t already know.  However, third parties have a different presentation and reputation that give them credibility.

 

Return on Security Investment – For more mature programs, whereas security devices and security testing are integrated into the daily process, return on security investment is the best motivator for management to provide additional support to the program.  Metrics must be measured in these organizations and statistics must be gathered constantly.  Metrics should be measured to show that particular practices such as doing a code review will actually save the company money vs. the current application testing process used within the organization.  Statistics from industry studies must be presented to management providing solid proof that particular security practices will actually save more money over time.

   

The Proposed Program – For newer security programs, whereas a CISO/CSO has recently been assigned (yes these organizations still do exist) and the security team is very small, a formal proposal and plan must be presented to management.  In this situation, the newly appointed CISO has a difficult job especially if the individual does not have an information security background.  A detailed plan must be developed and this plan must include education for management about the need for security.  The plan needs to explain in detail both short and long term plans for implementing different security controls based on risk assessment.  The key to implementing the plan is to bundle security with other ongoing and new projects.  It is much easier to take a little money here and there vs. asking for the entire budget.  Also, adding to each project will be beneficial later because you have already started integrating security with the different practices already in place.

What is Better? Process or Asset Risk Assessment

March 11, 2007 — 25 Comments

As many of you know this is one of the main projects in the ISM community and there are some different perspectives of the best method to perform and Risk Assessment.  I am really hoping to get some good feedback across industries on this question.

   

Where does the Risk Assessment methodology come from?

I know many asset risk assessments are based on the NIST and OCTAVE methods, which is usually the work I perform.  Many of the process based risk assessments I have seen are done by auditors (the Big 5 type companies).  When reviewing many of these I notice they all seem different, thus I’m not sure the method’s they follow (some use COBIT).  Most organizations I have consulted to use the Audit department to perform the process risk assessment while the asset risk assessment is usually done in a separate group or by information security. 

 

Asset Risk Assessment: Brief overview

The asset based risk assessment that I perform usually focuses on asset risk in terms of the people, processes, and technology.  With that said I do not map every process, like a process risk assessment.  The end result of the assessment is a list of asset groups (prioritized by severity), threats (assigned a value based on likelihood) mapped to each asset group, and vulnerabilities (ranked by impact and how easy it is to compromise) associated with each asset group.  All of these (assets, threats, vulnerabilities) have scores associated with them that when added up produce a risk score.  Then risk prioritized recommendations are created to remediate the vulnerabilities.

 

We need both!

Is the asset assessment better than a process assessment?  I don’t think so, but most organizations that I have consulted (on risk assessment) have problems with a process based risk assessment when it is done alone.  However, when combined together both methods usually cover most areas of risk.  Again, I don’t think either one is better than the other.  I believe we need a mechanism in place to assess both the asset and its associated processes.  

 

What is your view?

Enemy 1 & 2: Passwords and Patches

March 6, 2007 — Leave a comment

I could not help reading the Security 2.0 posts by Mark Curphey and I especially liked the Business Activity Monitoring discussion.  However, I see 2 major enemies that cause us pain every day and put organizations at great risk.  In my mind neither of these has been addressed properly.  

 

Enemy #1: Many internal penetration tests obtain the admin or root access by guessing passwords. 

Enemy #2: What do I say? Unpatched systems are an initial point of entry for many attacks both internally and externally.  Tools like Metasploit make it even easier.

   

Of course I’m not throwing out statistics, but I see first hand the results weekly.   One can only hope that the Security 2.0 solution addresses the problems with passwords and patches.

Security Program Development: Fundamentals of Staffing!

March 5, 2007 — Leave a comment

I wanted to kick off this blog with a little more serious discussion involving security program development. Therefore, I am putting out there my thoughts on information security staffing.

The Question

“How do you determine the appropriate level of security staff I need?”

It’s amazing how many times individuals at organizations want the bullet answer to this question. They ask, “Is there a dollar per staff ratio (1million:1staff) that can be used to see if my organization has the appropriate number of staff? Is there an employee to security staff ratio (1000:1) that I should be following?”

I find this topic important because there are some fundamental items that must be assessed before determining staff for any function within the organization.  For example, Let us talk about software development staff for a minute.  How do you determine how much development staff you need?  Can that question be answered with a ratio to IT staff?  Not really, not without a good deal of additional information. 

What do we need?

I’ve seen a few articles that try to calculate and answer this question.  One particularly I remember was an article using the approach identifying a primary and backup individual for each device platform.  In my experience, this is not practical or cost effective nor does this method use a risk based approach to security.  I think methods like these are missing the key fundamentals for determining staff.  What is that we need to determine the appropriate number in our organization?

Fundamentals of Staffing 

In my experience, I am in the unique situation of evaluating many organizations security staffing levels.  What I have determined is that organizations have more staff dedicated to information security then they really know.  The problem is that the staff is not functioning together as one entity.  A few fundamental items can be used to help management determine the appropriate staff levels.  These fundamentals can also be used to help security function as a single entity with a common goal.  The fundamentals are:

1.  Scope: Scope of information security within the organization.

2.  Requirements: The legal, compliance, and business requirements.

3.  Budget: Total organization budget, IT budget, and security budget.

4.  Roles and Responsibilities: The current and required roles and responsibilities (including the information security governance structure)

5. Time and Assessment: Current security posture, future security posture, and time to be compliant or obtain the future security posture. 

6. Management Support: Executive sponsor ship and commitment.

Putting it Together

Although these are not all encompassing and nor are they a silver bullet solution.  Obtaining this fundamental information in accordance with a risk assessment will help you identify the gaps in your requirements for reaching a particular security posture at a given point in time.  That information prioritized by the risk can be used to staff up accordingly and reach a common goal.

Remember all processes require updating constantly.  So does security staffing, whether it be with contractors or internal employees.  Don’t look at the problem trying to find the correct ratio for the appropriate number of security staff.  This number should be constantly changing based on the fundamentals provided above.  Information security like any other ongoing process must be dynamic and constantly changing to meet the organizations needs at a given point and time.