Threat Modeling and Security Assessments

Over the last several months, in creating a threat evaluation model / process and performing a security evaluation, I have come to several conclusions.

In creating a threat model, you must create a process that is repeatable, yet has some flexibility in it to meet different situations.  For example, evaluating threats and vulnerabilities against an operating system, such as what patches are missing, and what risk they bring to the current environment is different than evaluating a process for password management.  The threat model has to have some flexibility to ensure both cases are able to utilize the process.

The security evaluation of another company’s enterprise is more difficult that evaluating your own.    In my enterprise I know how management see risks in certain areas and I can gauge what the remediation effort will be based on the experience of working in my enterprise.  However, when evaluating another enterprise, is more difficult to know everything that may affect the risk score and remediation efforts.

Overall, the exercise was very good and a good bit of knowledge was gained.

Until next time…

~Skeeter

Creating an Action Plan from a Security Review

After all the work of performing a security review of an organization, it is time to create an action plan.   This plan must be something the client can use, so it must be.…..actionable.

How do you classify the threats and vulnerabilities that need to be addressed?   Do you do it by functional area, location, responsible area, severity, or by amount of effort to implement the recommendation?

I believe using a table format is the easiest to ready for the client.   Additionally, I believe breaking the table up by function area is also beneficial for the client.  I choose to list the deficiencies by risk level.  This allows the client to quickly identify the highest risk items for each section.  

The typical action plan table will have the following headings

Vulnerable Area/System - The area (Active Directory) or System (Checkpoint Firewall)
Threat Description - A short description of the threat / vulnerability.   The full description and/or risks will either be listed elsewhere in this report or in separate threat analysis report
Severity - The risk level of the threat...High, Medium, Low
Remediation Effort -  This is based on the amount of work that will be required to implement the specific control.  I prefer to use Costly, Moderate, Low.
Recommendation - This is the recommendation to correct the deficiency.  I choose to keep this at a high level, as details can be provided to each responsible area.

Finally, an appendix of definitions.  At a minimum it includes the definitions of the Risk ratings and Remediation Effort ratings.
 
Until next time....
~Skeeter

Threat & Vulnerability Mitigation – Asset Identification

No matter what you all your program (I call mine Vulnerability Management) to manage threats and vulnerabilities as they apply to your network and processing environment you must know what you have for assets. 

Assets ---equipment, operating systems, virtual environments, applications, infrastructure parts and pieces --- need to be identified by manufacture, make, model, version, etc...   While it will be a chore to initially identified and gather all the information of these assets; the hard part may be keeping the data current without proper processes in place.

When setting up the process to gather and keep the information current, keep in mind that it should be part of other processes.  For example, during the project phase for new systems, include a step to update the asset database.   Including a step in the change management process that requires an update of the asset database with the new information will ensure existing assets are kept current.

One of the items that is frequently forgot in the asset identification is the network infrastructure.  Don’t forget to identify the firewalls, proxy servers, VPN concentrators, switches, wireless equipment (switches and access points), and network management devices.   As a security professional, make sure you include your own systems, such as a SIEM, DLP, A/V and malware servers, and vulnerability scanners.

A key part of the tracking of threats against assets is knowing how the devices are configured and used in your environment.  An example would be Active Directory…what changes are made from the default configurations?   How does your password policy compare?   Is it weaker or stronger?   This could have an effect on the risk rating applied to a vulnerability identified for your operating system.

Once you have the assets of your IT environment identified, it is time to start down the identification of SCADA and other control systems…..good luck.

Until next time….

~Skeeter

How, What, and When to Patch

How an enterprise decides to manage patch administration probably varies based on who is doing it, the maturity of the Vulnerability Management program, and the business’ tolerance of maintenance windows.  In my opinion patching should be broken into four categories:

(1)  Infrastructure.  This would be servers, devices, applications that are used by IT and can be patched with no impact to business users or business processes.   This patching can be accomplished as often as necessary, but monthly will probably work out the best.

(2)  Servers / Operating Systems.  This category includes the Windows and / or Linux servers in the environment.  This is where IT management needs to get a recurring maintenance window from the business that is always available for IT to use whether it is needed or not.   In my humble opinion this window should be available weekly.   While we are probably not going to patch weekly, this windows can be used to fix application problems, apply emergency / critical patches, etc…   Server patching probably can’t be performed more that quarterly because you will need time to test patches in the non-prod environment.

(3)  Applications.   This category includes business applications such as ERP systems, HR systems, etc…   These systems should be patched during the maintenance window arranged by IT management above.  How often this patching occurs will depend on the business’ desire because it will take good amount of resources to test the patches and identify any impacts on systems that may feed or receive data from the patched system.   Twice a year maybe the best case scenario; once a year maybe the answer the schedule that works best for the business.

(4)  Workstations.  This is where the biggest risk may be located for the enterprise.  While the endpoint security (anti-virus, anti-malware, etc…) should be updating daily, OS patching should be applied monthly.  If a standard desktop image is used, testing should be pretty straightforward and a reboot by users once a month isn’t to much to ask.

No matter what schedule an enterprise decides on, the key is management buy-in and communications to the user community.   Once the schedule is set, stick to it and only deviate in rare and unique situations.

Until next time…

~Skeeter

Vulnerability Sites ---- revisited

Several weeks ago I posted a list of sites and links where threat and vulnerability information can be gathered from.   Since then I have again had the privilege of running a number of scenarios through my threat process model and want to up you on the applicability of the links I provided.

My recent research confirmed the format of http://www.securityfocus.com where you can search via drop downs.  For example you select Cisco, then all Cisco products are presented and you can select the product in question.   If the product has versions, you may also select that.   I also visited the Cisco website to search for vulnerabilities on their Nexus 7000, although several showed up, the site doesn’t tell you directly that a fix has been released.  

http://web.nvd.nist.gov  also served me well, but you must know exactly what you want to search for vs. the menu options of the securityfocus site.

For operating systems, such as Windows 2008, the NVD site works very well for searching.  It will list all the vulnerabilities and provide a link to the vendors site, in this case to Microsoft Technet and the 2008 security bulletin.

For other situations such as VMware ESXi or a Belkin router, I would continue to use the NVD site to search for vulnerabilities and visit the vendor site if more information was needed regarding patch status.

Until next time…

~Skeeter

Controlling Privileged Access

First, I define privileged access as anything above what the standard user would get?  How do you control privileged access?   Do you allow your Linux system administrators to have the root password?   Do you Windows administrators have the password for a system account with admin privileges?  Or maybe they have domain admin rights assigned to their personal account.

A while back I attended a presentation about for a product that stores the passwords for accounts…the assumption is that all privileged accounts would be stored in this solution along with the passwords.  This system is also capable of being integrated with AD and your ticketing system so when a user needed the password, the system would check to make sure there is a valid ticket (incident or change request) and that the requestor is also in the right AD group.  This security solution will also change the password after a set amount of time from when the password was retrieved.   This would seemingly prevent the user from reusing the password for an unlimited about of time.

While I can see why management and Internal Audit would love this solution….on the surface it meets the compliance requirements for controlling access and assists with the change management process.  This system is also very useful in storing passwords that don’t get used very often, thus making sure they are available in a business continuity situation.   However, does it help a company be secure or does it give a false sense of security?    

What are the actual actions performed when the password is retrieved?   The IT guy could retrieve the password and make any change under the guise of whatever the Incident or Change ticket talked about.   Every environment has those system accounts where the password is never changed.  These accounts tend to have a high level of privileges and everyone on the team knows the password….so no trouble ticket is required to use these accounts.   I could go on and on, but you get the point.

What is the solution?  So will argue that the administrators need admin privileges all the time….it is their job.   I don’t necessarily disagree with that.   I believe the solution lies in monitoring what the privileged accounts are doing.   Implementing one of the solutions that monitors key folders, directories, and files for access and modification is also needed.   

Until next time…

~Skeeter

Data Protection at all Levels

We all know that we need to protect the employee and customer data from unauthorized access.  We also are aware that there are many rules around the storing and transmitting healthcare and credit card data.  Most of us have went to great lengths to put security controls in place on our Production environments to protect this sensitive data in accordance with applicable policies, rules, and regulations.

What have you done to protect the data on your non-production networks?  If you have a test / QA environment that is used for functional, security, and user acceptance testing, what data is being used to ensure testing is against the “exact” data that is in Production?   Some enterprises might use an extract of the data from Production in lower landscapes for their testing.  Are all of the same security controls in place in the test / QA environment?  Or have the controls around privileged access been relaxed to make it easier for testing?   Or maybe you have password standards (probably relaxed) in the test environment? 

What about the development environment, I am guessing the security controls are even more relaxed for DEV.  The developers probably have access to just about everything and are able to manipulate the security controls to make their job easier.  Where did the data come from that they are developing against?   Was it copied straight from Prod or was it scrambled?   Or maybe if you are lucky, the developer just created their own data to use.

I understand the need to use properly formatted data…..but if you are going to use any sensitive data from the Production environment (include employee database for a HR system, sensitive company for an ERP system, customer data for customer relationship database, etc….) make sure it scrambled in some manner to make it seem that it is just random data.    Also, don’t allow the key security controls to be removed in the lower landscapes, make the developers and testers understand the need for the controls.

Until next time…..

~Skeeter

Threats, Vulnerabilities, and News…where do you get your infomation?

As all Information Security professionals, I have my favorite feed, blogs, and sites I visit for my security news. Before I conclude this blog I will share mine.   However, where do you go for your intelligence related to threats and vulnerabilities?   This would be the sources that give you the technical details, usually always in a standard format that the subscribers have come accustomed to.

For vulnerabilities, since CVE (Common Vulnerabilities and Exposures) is the standard tracking of issues with software, every Information Security professional should subscribe to a source that disseminates new CVEs.   One such source is to use the RSS feed from the National Vulnerability Database (http://nvd.nist.gov/).   Although if you don’t have lot of different operating systems and software applications, they volume may be too much to digest.

Cert (http://www.kb.cert.org/vuls/) also provides a rss feed that will supply identified vulnerabilities.  Another source our team uses is http://www.securityfocus.com/ and don’t forget http://www.us-cert.gov/ or http://securityfocus.com.  Usually after a vulnerability has been identified for a system I oversee, other sources, such as the vendor’s website, will be reviewed for additional information.  If the vulnerability looks like it may be high risk, don’t be afraid to question you customer representative from the company.

For general news and opinions of breaches, threats, and vulnerabilities I have several sites I visit daily (usually while I am eating lunch):

• Dark Reading (http://www.darkreading.com) – they have cover a wide range of IT areas and have a good group of contributors
• SANS (http://www.sans.org/newsletters/) – their newsletter provides a high-level recap of the top security stories for the week
• InfoSec Island (http://www.infosecisland.com/) – a good collection of blogs.  Pick a couple of follow
• Computer World has a Security Manager blog that is ghost written.   Although not news, I do enjoy reading the issues this manager is having.
• PaulDotCom (http://www.pauldotcom.com) – I try to listen to their pod cast every week as they have some very good guests and the staff is very knowledgeable.  And I never miss John and his latest episode of Hack Naked TV.   The site also has a ton of helpful technical information  (yes, I may have saved the best for last)

Once you find a couple of good sites, share them with another Information Security professional, I am sure they will share a new site with you.

~Skeeter

Where Work-Life Balance Meets Information Security

With people being more connected with their job through laptops, tablets, smart phones, etc… it seems that more companies are worried about work life balance.  Some companies may define work life balance as giving employees more “privileges” with their company-owned computing assets.  By privileges I mean that they may allow the employees to do more with the company owned laptop or loosen the restrictions on what websites can be visited on the company network.

For example, some companies may let employees check personal, web-based email while on the company’s network.   Other companies may allow employees to visit Facebook while others block it. As companies come to expect employees to be connected 24/7 to work, I understand the need to allow employees some freedom at work to get away from the daily grind for a few minutes.  But allowing the freedom comes with some risk, and that risk needs to be discussed before the decisions are made.

By allowing employees to visit Facebook, the company has opened up a new attack vector into the company’s network.  Before opening it up, maybe a company needs to evaluate the reliability of their desktop protection software or look at a solution that will detect malicious traffic at the network border.  The same issues are present if a company allows employees to check personal email at work.  Additionally, if the connection is SSL, is the company going to break the SSL connection and monitor the traffic? What traffic is off-limits to monitoring?  What websites will be blocked and does the proxy server / service have a good track record of classifying websites? I suspect the HR and Legal will want to weigh in.  

I am not saying what is right or wrong, but management must include Information Security in the discussion prior to making decisions based on what is allowed on the network and what employees can do on their company-owned computing devices. 

Until next time...
~Skeeter