March 17, 2009

Security Breach Resources

Posted in Identity Theft, Security Awareness, Security Governance, Threats at 7:19 pm by jtbevis

Pulling security breach trends for different industries the past few months I came across a few good sources to help anyone that needs specific data.

Two sites I found with an abundance of information were:

Privacyrights.org hosts a chronological list of breaches several years back until present date with a brief description of the breach and the number of records affected.

 

Datalossdb.org hosts the actual breach notification letters that have been sent out.

For statistics and trends use these resources.

 

In general it looks like breaches frequency is about the same in 2007 and 2008.  Problems seem to be related to basic items such as laptop theft, data left unencrypted, and your usual intruder attack.

March 4, 2009

HIPAA and the Stimulus Bill

Posted in Security Governance at 4:48 pm by jtbevis

Is HIPAA Really changing?

Here is a good summary link of the changes.

I think John did a good job outlining the key changes.  There is no point in regurgitating the information he has already covered in detail.  Overall there are changes to penalties, new breach rules, business associate responsibilities, and more.

What I find interesting is that according to his article HHS is now responsible for issuing guidance specifying technologies and methodologies.  To date I haven’t seen anything yet posted on their site, but they have until February 17, 2010 before the Act is in effect.

I believe many government based organizations currently fail these controls miserably.  It will be good to start seeing some accountability.  I just hope they lay out the expectations clearly unlike when PCI was first issued.  I also hope there is some visibility into the ratings of each entity moving forward.

In the mean time here are a few good older links to help entities make sure they are at least in tune with current expectations.

January 30, 2009

Authoritative List of Compliance Documents

Posted in Policy and Compliance, Risk Assessment, Security Governance, Security Program Development at 9:08 pm by jtbevis

For anyone looking to find or understand the main key compliance documents across the following industries, regulations, regions of the world the link below has a good list.

http://www.unifiedcompliance.com/matrices/ucf_ad_list.html

Industries, Regulations, Regions:

  • Sarbanes Oxley Guidance
  • Banking and Finance Guidance
  • NASD NYSE Guidance
  • Healthcare and Life Science Guidance
  • Energy Guidance
  • US Federal Security Guidance
  • US Internal Revenue Guidance
  • Records Management Guidance
  • NIST Guidance
  • ISO Guidance
  • ITIL Guidance
  • US Federal Privacy Guidance
  • US State Laws Guidance
  • EU Guidance
  • UK and Canadian Guidance
  • Other European and African Guidance
  • Asia and Pacific Rim Guidance
  • System Configuration Guidance

Also, some of these are already linked off this site.  If anyone is feeling like they have some free time feel free to send me links to the listed documents and I will add them to the Links page.

January 12, 2009

Working Toward ISO 17799/27001 Business Continuity Management Compliance

Posted in Business Continuity, Policy and Compliance, Security Program Development at 9:21 pm by jtbevis

This document is written with the assumption that the organization follows ISO and has implemented many of the controls (including Disaster Recovery), but may be lacking in the area of business continuity management. This document aims to consolidate and leverage the work already done for other ISO controls to jumpstart the BCP compliance efforts.

 

The first step in compliance is to develop and implement a BCP management process.  The process needs to identify the critical business processes within the organization and incorporate management requirements.

 

Process:

  1. Identify critical business processes and associated assets.  Create a template or leverage the disaster recovery (DR) documentation (Note:  The DR information may not be complete enough as it usually only includes recovery of technology functions and may exclude important business functions or process that do not rely on technology.) and send to managers requiring them to document their critical business processes by location.
  2. Identify the consequences in the event of a disaster.  Again most of this should be in a DR plan.
  3. Identify controls to reduce risk.
  4. Ensure information for business operations is available.
  5. Ensure BCP is integrated within business processes and includes security.
  6. Ensure that plans are updated and tested on a regular basis.

 

Below is a sample that can be used and quickly put together to help meet some of this compliance.  Use Excel and list the critical business processes in a matrix associated with each geographic location as shown below.

 

 bcp-iso1

 

The next step is to identity the results of different events by doing a business impact analysis.  Continuity plans have to be developed to for quick restoration of operations and should be integrated with information security and other key management processes.  Controls that can be put in place to reduce risk should be identified.

 

The Threat should define “Who”

The Event should define “What, Where, and When”

 

 bcp-iso21

 

The table below is an expansion of the above.  (Threats are repeated for consistency)

 

 bcp-iso31

 

After the assessment the following must be done:

  • Continuity plan(s) must be created.
  • Roles and responsibilities must be documented.  Most should have already been done for other ISO controls, but there may need to be a few short statements added to reflect business continuity compliance.
  • Procedures and processes must be documented.  Many of these should have already been documented as a part of incident response, disaster recovery, change control, and other standard operations.  A few additional procedures may need to be created like the process of documenting and updating plans.

 

Plans must have the same framework.  This means all departmental plans must be a on a standard template.  A centralized escalation and evacuation plan should be developed.  Evacuation plans can simply state follow building evacuation procedures.  Escalation plans in most cases can follow standard disaster, emergency services, or incident response plans.

 

Plans need to address:

  • Roles and responsibilities of key staff (i.e. BCP coordinator, executive management, and users)
  • Summary pointing to the documents that have recovery procedures for operations.  In many cases these procedures are in the disaster recovery area or part of the standard operating function.
  • Testing of plans.  This needs to track and schedule each element and when its tested. 
  • Storage of plans at alternate locations
  • Ownership of plans
  • Fallback procedures
  • Resumption procedures
  • Awareness and Training
  • Review of plan(s)

 

Putting everything important together is the key to the business continuity plan.  Many of the items above exist within many organizations but they have not been organized or consolidated in one area.  A document detailing each of these items and consolidating them all in one location is the key to passing the assessment.  If you are already working towards ISO compliance then Business Continuity Management is just one more minor component that can be accomplished quickly by consolidating a large amount of information in one place and creating a document (plan) that organizes and explains everything that needs to be done with these documents if there disruption to business operations.  In some cases there may need to be department level plans that are a close mirror to the main plan but focus more on departmental operations.  Some assessments will look for both centralized and departmental plans.

 

For more information you can also review that actual ISO/IEC 17799/27001 documentation and the BS 25999-2 Specification.

November 5, 2008

New Foundstone Free Tool DIRE – Software Security

Posted in Software Security at 7:29 pm by jtbevis

 

Attackers can target systems by exploiting ‘insecurely registered applications’. Foundstone has released a free tool called DIRE, which allows users/system administrators to identify “insecurely registered applications” on their systems.  Good for Developers!

 

Tool:

http://www.foundstone.com/us/resources/proddesc/diredetectinginsecurelyregisteredexecutables.htm

Whitepaper:

 

http://www.foundstone.com/us/pdf/whitepapers/fs_wp_securely_registering_applications.pdf

Thanks to Neelay Shah and his awesome work.

September 10, 2008

IT Security Spending 10% of IT Operating Budget

Posted in Security Governance, Security Program Development at 3:06 pm by jtbevis

10% of IT budget seems high.  It would be nice if someone provided an industry breakdown.  I can’t imagine that certain industries are even close to this number.  Resource links to the posting are below.

August 19, 2008

The Top Ten Convention Information Security Measures

Posted in Security Awareness, Security Governance, Security Program Development at 2:20 am by jtbevis

The Ten Most Important Things That The CSO Of The Republican and Democratic Conventions Should Be Doing To Ensure The Security of The Event

 

Overview

In 2004 I had the unique responsibility of being CSO for the Republican convention in NYC.  My role was primarily to secure the campaign network and work with the host committee to ensure security of their network.  To help those currently in similar positions or involved with other short time events and conventions I complied the top 10 measures that helped keep our environment secure.  In no way is this list complete, but the most important items have been listed.  This list also does not address obtaining management support or developing security policy, which are two fundamental elements to implementing all of the measures described below.

 

The Top Ten

The Convention Security Top Ten Security Measures (in no particular order) are: 

  1. Change Passwords Frequently
  2. Implement External Network Filtering
  3. Physically Separate Speech Network
  4. Change Voice Mail Messages
  5. Review User Accounts and Access Lists  
  6. Create an Incident Response Plan
  7. Enforce a no Wireless Policy
  8. Implement Intrusion Prevention
  9. Implement Disaster Recovery Plan
  10. Continually Walk Around and Assess

   

What makes Convention Security so Different? 

  • There is no permanent IT staff, organization, or existing IT documentation.
  • Everything done for the convention is temporary; everything must be taken down and returned a few days after the convention.
  • The project must be completed by the date of the convention. There is no room for failure.
  • Many decisions are based upon political considerations, including the appointment of key IT personnel. 
  • IT budget is usually “raised” specifically for this event.  In the case of the Democratic and Republican convention all funds are usually dual-approved between Host Committee and Campaign.
  • Political conventions have a major emphasis on IT security: it’s a National Special Security Event (NSSE) (i.e. involves Homeland Security, US Secret Service, FBI, NYPD and CERT).
  • Short timeframe in some cases only 30 to 60 days to install the IT infrastructure in convention sites.
  • No IT Program Management or Project Management structure.
  •   

    Top Ten Detailed Measures

    On the following pages is a description of each security measure with actual real world examples used in the Republican National Convention of 2004.

      

    1.  Change Passwords Frequently

    Based on my experience passwords are the number one way an attacker will gain access to a computer system.  The attacker gets in because the password is either the default supplied by the vendor, blank, easily guessable, written down, or typed in a file on another system.  Therefore, change all passwords as often as possible including system accounts, users, mobile devices, firewalls, routers, etc.  Don’t wait until the last minute to find out your blackberry servers bsadmin service password is “blackberry”. 

    Changing passwords at first will be painful for the users, but this is a must for event security due to turn over of employees, use of volunteers, and maintaining control of the systems under management of the security staff.  During the week of the convention IT should try not to change any passwords.  In fact ALL CHANGES should be frozen during the week of the convention unless there is some emergency.

     

    2.  Implement External Network Filtering

    Implement external firewall and router ACL filters that exclude every country outside of the US.  There are very good lists that can reduce your IPS hits from 100,000s a day to 100s a day.

     

    See my IP black list posting

    http://infosecalways.com/2007/11/08/ip-address-blacklist/

     

    3: Physically Separate Speech Network

    Usually in a convention there are a series of speeches given by well known individuals.  In the 2004 convention there were several important people speaking like Arnold Schwarzenegger, Dick Chaney, and the President George W. Bush.  The original network design was setup with the speech network connected to the Host Committee and Campaign network, which were connected to the internet.  The worst possible scenario would be hacking the speech system prior to the event or when the actual candidate was talking on live TV.  Thus, as a security professional it is important to separate the speech network and make sure there is no way any user on the internet has any chance to connect to these systems. 

     

    In the 2004 convention, amazing as it was, the speech server was placed in an Xray room at Madison square garden.  With the level of paranoia the fuses were pulled on the Xray machine and a separate pad lock was purchased and put on the door.  We called this the red room because the outside had a red Danger sign on the door because of the Xray system and it was in the Red Zone.  The only system on that same network was a Cisco network IDS server and only three individuals had access to the room. 

     This room located was in the Red Zone; the secret service controlled area that restricted access to the under stage and candidate environment.  Only four IT staff members had access to this zone.  For the 2004 convention the staff that had access was the CIO, the CSO, the Cisco engineer that ran the network cables, and an intern with political connections who administrated the badge system along side the secret service.  

     

     

    4: Change Voice Mail Messages

    This has to be one of those hard lessons learned for some of the IT staff at the 2004 convention because several employees were harassed for weeks during the convention as a result of their voice mail messages.  Many of the IT staff didn’t use office phones because there were several other means of communication such as cell phones, NextTel click to talk phones, and Blackberry devices. 

     

    Social engineering attacks are a very big threat for several months prior to the convention.  As CSO you will need to talk to the front desk staff and find out actually how many calls come in.  Many of them will come in from the other party (i.e. Democratic Party in this case).  The week of the convention the front desk staff was so used to these calls that the majority of them were just transferred to the main desk at the Democratic convention.

     

    The main problem that affected the technology staff was not just the political activists, it was the individuals that listed to voice mail messages and was smart enough to identify the IT staff and then harass them later.  In one case we had one specific vendor, who will remain anonymous, that left their company name and cell phone number on the voice mail.  When the harassing attack occurred this person was receiving several calls a day on their personal cell phone and ended up contacting the local police who continued the investigation.  In the end basically you will have to change your cell phone, so it is important to change all of the technical staff voice messages to avoid social engineering and harassing attacks.  Remove names, titles, cell phone numbers, etc.  You don’t want your top IT staff getting spammed with calls that essentially DOS their cell phones because they left the number and their title on their office phone.

     

    5: Review User Accounts and Access Lists

    Continually review user accounts and access lists to systems, applications, network devices and datacenters frequently.  You might be amazed how many volunteers have access and other staff members that no longer work for the convention.  This is a must and should be done several times before the event.

     

    6: Create an Incident Response Plan

    Create a solid response plan and make sure that CERT (http://www.cert.org/) and the Secret Service are included.  Although spam may be your only incident it will be important to have worked out who to call first and who can investigate the incident.  During the 2004 convention we came across four items that could be classified as incidents.  These were social engineering, DOS attempts, data leakage, and spam.

     

    Social engineering was discussed above in item 4: Change Voice Mail Messages, DOS attempts were targeted at the campaign web site which was externally hosted with an infrastructure capable of the traffic.  During setup we performed a site inspection of the third party and required additional technology implemented for preventative measures.  Data Leakage occurred and we were notified after it hit the media.  The problem turned out to be an internal volunteer that leaked an Excel file of Campaign names to the media.  This is always a difficult and costly problem to solve, but in this case the repercussions were small and had little affect other then media coverage.  Then our one major incident that we fully enacted the IR plan turned out to be confusion among a spam email that got through the filter and was titled something along the lines of “you’ve been hacked”.  It turns out it the message was a spam email for a video tape that some delegate received and thought his system was compromised.  Overall the process worked great based on after incident feedback.  The process for this is below.

     

    Incident Response Process Flow Example:

     

    Enforce the “need to know” policy.  Tell the details of an Incident to the minimum people necessary. 

     

    1. Initiate the Investigation. 
    2. Can you confirm this is an incident? If yes go to step 5. If no go to step 4.
    3. Make note on Incident report form and explain that it was not an incident; Go to Step 15.
    4. Notify the Secret Service. 
    5. Activate the Incident Response Team.  Fill out the Incident Report Form (Appendix D).
    6. Continue Investigation.
    7. Were systems on the network affected? If yes go to step 9, If no go to step 10
    8. Notify staff and administrators on affected system(s). If dispatched to a site remember to document location.  Go to step 10
    9. Is there a possibility of criminal action? If yes go to step 11. If no go to step 12.
    10. Notify the Secret Service and wait for instruction. Do only as they say.
    11. Contain and/or isolate victim system(s).  If this is a virus or worm unplug the system from the network.  DO NOT power down the system because some viruses may delete information when the system is rebooted.  If it is NOT a virus or worm disconnect the network or do a hard shutdown of the system.  DO NOT do a graceful shutdown because valuable information may be lost.  Log all actions.
    12. Notify the Secret Service.  Log all actions.
    13. Return the system to normal operation.  Log all actions.
    14. Incident over.  Fill out Incident Report Form (Appendix D).  List all actions.
    15. Hold a short meeting with the Incident Response Team, CERT, and Secret Service to identify the Lessons Learned and adjust the program accordingly.  List all actions.

     

    7. Enforce a no Wireless Policy

    This is just a simple solution.  Wireless is not secure enough, hard to monitor, and should be turned off on every device connected to the network.  Make sure that all laptops have the wireless setting disabled too.  Only use blackberry and Nextel type devices.  You don’t want any one with a wireless card bridging in external networks or something worse. 

     

    It’s a hard enough job to ensure that everything is shut down; let alone trying to monitor outsiders connecting to the network.  The Secret Service may also block wireless at different time (though they can neither confirm nor deny that!), which may cause disruptions of signals.

     

    During the convention at night when the speeches were being conducted the main job of the CSO and the IT support staff was to simply monitor wireless systems and ensure that no device was connected to our network cables. 

     

    8. Implement Intrusion Prevention

    Install both network and host intrusion prevention.  There will be viruses so this combined with anti-virus will stop propagation.  Behavioral based solutions work very well and should be installed on every system.  Below is a diagram for the network with the placement of network IDS systems.

     

    RNC Network
    RNC Network

     

     

     

     

    9. Implement Disaster Recovery Plan

    Implement redundancy for all equipment and possible circumstances.  In most cases communication is the most important item so ensure email and other services are redundant and located offsite.

     

    10. Continually Walk Around and Assess

    Check cabling, wiring closets, and wireless access points (that shouldn’t be there) by walking around the facilities regularly and constantly scanning for wireless devices.  It’s amazing how many people have access to your wiring closets.  Its also amazing when you find water dripping on your cords, so check everything multiple times. 

     

     

     

     

     

     

June 6, 2008

Risk Based Security Plan – Whitepaper

Posted in Risk Assessment, Security Governance, Security Program Development, Security Staffing at 11:14 pm by jtbevis

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. 

 

May 9, 2008

Information Security Staffing – Skills Identification and Training Budget

Posted in Security Awareness, Security Governance, Security Program Development, Security Staffing at 11:21 pm by jtbevis

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.

December 28, 2007

More on MAC Security

Posted in Patches, Security Awareness, Threats at 3:37 pm by jtbevis

So it appears Gartner has something to say about MAC security too.  Here is an interesting article building on the MAC security issue.  It’s just a matter of time before a major attack happens that hits the MAC platform.  Another interesting tidbit is that the article points out that “Mac’s generally have to be patched one at a time”.  Don’t get me wrong using both Macs and PCs can be good if the overall strategy supports security, but the key here is not to have a false sense of security.

 

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

Previous page · Next page

Follow

Get every new post delivered to your Inbox.