This whitepaper has a good overview of key components of a risk based security plan, which have been put into practice on several occasions.  This provides good direction with a decent amount of detail. 

Site Requires Registration:

http://searchsecurity.bitpipe.com/detail/RES/1212429613_869.html 

The document is about 12 pages explaining the steps for performing a risk assessment to developing a security plan to determining security budget. 

One of the key problems a security manger must tackle is defining the budget for security training.  Many awareness program guides break it out into a method similar to the following:

1. Identify security roles and responsibilities
2. Conduct a needs assessment
3. Identify the gaps
4. Develop and implement the training plan

Skills Identification

The key step here is the identification of roles and responsibilities.  Identification of security roles and responsibilities is probably one of the most important fundamental aspects to a successful security program.  Although, writing sample roles and responsibilities or breaking out each of the above steps is not the focus of this topic, it is important when defining the core security staff’s training to build on the role definitions by creating a skills identification table.  A skills identification table will work for most organizations because it provides a quick profile of each security professional.  To create a skills identification use excel or a similar program and setup a structure similar to the one shown in the table below.

List each employee in the security program in the left column and then ask each one of them to fill in their certifications and training.  Columns should be added for all security certifications and training associated with employees.  This information will provide the security leader with the organizations current security capabilities.  It will also be easier for the security leader to assign the appropriate personnel to security issues based on their training and certifications.  For career planning you could also expand this model to include a section for desired certifications, training, or expertise.

Applying to Budget 

Now that each employee has provided their information the identification table can be used to help with the annual training budget.  Ideally the security leader should set the annual training budget for at least one training session a year for each employee.  The security leader should also take one training a year, but if cost becomes an issue then offset the security leader training by attending conferences and conventions.  If possible training schedules and classes can be used to prepare for new corporate projects by attending training with specific project needs.  Otherwise training should be defined with each employee based on their career goals and the goals of the organization.

Depending on the size of the core security team an average week of training may cost anywhere from $2500 to $5000 depending on location and accommodations.  To define and annual budget take the number of staff and budget for the $5,000 per person annually.  For example, 5 core security staff should have an annual budget of $25,000 dedicated solely to security training.  Determining the actual classes beforehand will help predict the budget more accurately and possibly save costs on travel.  If you are in a large organization, especially one that is decentralized the budget may increase significantly.  One way to reduce the cost is to identify key security gaps, such as application security, and pay for onsite training.  In this situation budgeting will have to be performed by contacting a vendor(s) to obtain pricing quotes.  Keep in mind there may be an issue with taking a large amount of employees away from their regular work. 

Overall there are several advantages to this staffing an budgeting approach.  One immediate advantage of increasing the security training may be reduced consulting costs.  Another advantage will be increased employee moral, as well as improvement of overall security.

 http://news.yahoo.com/s/infoworld/20071228/tc_infoworld/94177;_ylt=AmF8ijFNlThIuDkLJJ6MHJEE1vAI

An article was recently published about the Army adding Macs to improve security.  Although diversifying vendors will usually make you more secure if used to support a defense-in-depth strategy, the context of the article supports a lack of knowledge or evidence to support the statements made on the Army’s part. 

Article in Full:

http://news.yahoo.com/s/nf/20071224/bs_nf/57382;_ylt=AtIAHN4BI3dTDzpNM.n7xA8E1vAI

There is one particular statement that is worrisome whereas the Army security spokes person has been quoted “Apple’s version of Unix is inherently more secure than Windows”.  Now I don’t claim to know all the facts but if you look at the links provided below the Mac OSx falls behind in 2007 and in the year 2004 has less advisories, but remains equally comparative percentage wise in regards to the number of critical vulnerabilities.

2007 Stats:

http://blogs.zdnet.com/security/?p=758

2004 Stats:

http://www.techworld.com/security/news/index.cfm?newsid=1798

Fortunately the article has a counter argument by Charlie Miller at the end supporting the fact that the Army needs to step it up with more then Macs when it comes to security strategy.  He comments about Mac being “behind the curve in security”.  Also has a great reference stating “In the story of the three little pigs, did diversifying their defenses help? Not for the pig in the straw house.”  On the other hand diversifying is good if you use one product to backup the function of another project in the event one fails.  So even though the pigs straw house was destroyed if that third pig could get to the brick house it would still survive.

There is an article that came out earlier from DRJ (Thomas L. Weems) based on a study that provides guidelines on the required geographical distance for alternate site locations.  This is good news for those performing risk assessments where this is considered vulnerability, because as far as I know FEMA has provided no specific guidelines. 

http://www.drj.com/articles/spr03/1602-02.html (registration required to view)

Ideally 105 miles point to point is the key number for all the threats listed below.  For those who don’t have access to the article below is a breakdown of the recommended geographical distances based on the threat.

NOTE: The article provides a graph so the numbers below is based on my interpretation of the graph.

Alternate Site Distance Recommendations

Hurricane:  105
Volcano:   75
Snow/Sleet/Ice:  70
Earthquake:  60
Tsunami:  52
Flood:   48
Military Installation: 45
Forest Fire:  42
Power Grid:  36
Tornado:  35
Central Office:  29
Civilian Airport: 28
None of the Above: 21

Off Site Storage Facility Distance Recommendations

Hurricane:  85
Volcano:  64
Snow/Sleet/Ice:  56
Tsunami:  45
Earthquake:  43
Flood:   43
Military Installation: 41
Forest Fire:  38
Power Grid:  36
Central Office:  25
Tornado:  24
None of the Above: 24
Civilian Airport: 22

Also the key here is to remember that the off site storage facility should accessible from the alternate site facility, which is a mistake many organizations make.

Problems and Revisions

Based on some quick research there are a few problems with the current distances above.  For example, I took three common disasters and did a quick analysis and here are the results along with some suggested changes.

Hurricane – Katrina spanned a much larger distance then 105 files proving that this distance is not adequate in a very large hurricane storm.  The article below explains that Katrina expanded over 780 miles whereas the outer regions were probably only affected by rain.  However, from my research severe damage was over about a 200 mile radius.  Therefore, I would suggest doubling the current metric to 210 miles.

http://earthobservatory.nasa.gov/NaturalHazards/shownh.php3?img_id=13083

Volcanoes – Although the current figure will probably be fine in most cases there is information to support that volcanoes can spread ashes up to 100 miles as displayed in the below article.  Therefore, this number should be revised to 105 miles based on the type of volcano.

http://pubs.usgs.gov/gip/volc/types.html

Earthquake – Similar to the volcano this distance will probably be sufficient but why take the chance when there is evidence that a 7.8 earthquake ruptured 220 miles of a fault.  Therefore, this number and the definition should be clarified to be at least 60 miles from a major fault line.

http://www.earthquakecountry.info/roots/shaking.html

On strategic risk assessments not testing the anti-virus signatures before being deployed should be considered a vulnerability.  Many of my customers believe this is ridiculous and not practical, however I report it anyway.   Whatever the case, the organization has the decision to accept the risk, as I am only there to point it out.  There is a great example published where a routine update caused serious problems forcing customers to have to re-install the operating system.

 http://news.yahoo.com/s/zd/20071206/tc_zd/221141;_ylt=AhIN_X.SMrgYGlzdK7zmNe8E1vAI

So you decide.  Should Anti-virus software be tested before deployment.

Interesting article came out yesterday saying “hackers in China are believed responsible for four out of five major cyber attacks on government targets in 2007″. 

http://news.yahoo.com/s/ap/20071129/ap_on_hi_te/mcafee_cybercrime_report;_ylt=Anbi.FL2E0D0ceU15GAZZ94E1vAI

Although, I’m in no place to confirm or deny this research my expierence shows that the majority of actual incidents (The organization has been hacked) usually come from ASIA pacfic (Korea, China) or from internal employees.

To protect from the ASIA pacfic consider blocking the IP ranges listed in my IP Blacklist Post.  Internal incidents are usually a result of too much trust of internal employees and lack of segregation of duties between functions.

Malware is everywhere and becoming one of the most common security threats in the industry.  The link below provides some insight into the seriousness of this issue.

• http://seclists.org/fulldisclosure/2007/Oct/0892.html

There really is not a great solution for this problem at this time, but how can a company that serves adds mitigate the risk.  There are several ways.

1. Ensure all ads that are uploaded are hashed in some way to ensure the add being delivered is the add uploaded by the client.

2. Use file monitoring tools like tripwire on image servers to help ensure that adds are not modified.  This will also help provide proof if there is an actual attack on the add server.

3. Scan adds with anti-virus software.  Although this will not catch everything it will catch some of the files.

4. Scan adds for known malware URL’s to prevent phishing type attacks.  (This is like a signature based solution and takes a great deal of maintenance to keep up with the attackers)

5. Hope someone comes up with a good solution that can regularly scan all the adds for malware.

The above will help limit the liability of the ad company serving adds and has some preventive measures that can be implemented to protect both the add companies brand and their customers who may be uploading malware adds without knowing it.

IP Address Blacklists are great for short time security events.  This information is important for a paper that I am working.  It took me a while to find this information again.  I actually had to dig into an old email file to get all of the information because typical internet search engines were not providing good results. 

Here is a good list of IP addresses and ranges that can be blacklisted to help prevent DOS attacks, etc.  Before using this list be sure your organization does not have clients in the below ranges.   

 Dshield Top 10 Attack IP’s

http://www.dshield.org/top10.php

•  074.052.180.114
•  218.003.209.174
•  211.106.172.081
• 195.068.089.211
• 121.015.253.104
•  218.004.137.213
•  202.062.224.090
• 150.164.029.253
•  058.215.065.237
•  218.006.009.099 

Dshield Recommend Block List

http://feeds.dshield.org/block.txt

 Asia Pacific Black List

http://www.apnic.net/db/ranges.html#country

•  58.0.0.0/8
•  59.0.0.0/8
•  60.0.0.0/8
•  61.0.0.0/8
• 116.0.0.0/8
• 117.0.0.0/8
• 118.0.0.0/8
• 119.0.0.0/8
• 120.0.0.0/8
• 121.0.0.0/8
• 122.0.0.0/8
• 123.0.0.0/8
• 124.0.0.0/8
• 125.0.0.0/8
• 126.0.0.0/8
• 169.208.0.0/12
•  202.0.0.0/8
•  203.0.0.0/8
•  210.0.0.0/8
•  211.0.0.0/8
•  218.0.0.0/8
•  219.0.0.0/8
• 220.0.0.0/8
• 221.0.0.0/8
• 222.0.0.0/8 

Its about time!  Foundstone Professional Services has been added to the Avert Labs research blog.  So now the makers of all the free hacking tools are accessible online.  Check it out there are already some great posts. 

 http://www.avertlabs.com/research/blog/index.php/category/foundstone/

I’ve also added it as a Blogroll.