Welcome to SecureState's Blog!

Calendar

<<  May 2012  >>
MoTuWeThFrSaSu
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar

Category list

Sign in

Information Security Assessments You’ve Never Had (But Should)

clock October 26, 2011 06:30 by author Stephen Marchewitz

 

You probably are familiar with the classic security assessments:  internal and external penetration testing, security risk assessments, and PCI gap assessments.  You may not be as familiar with, or even aware of, other assessments that may be just as valuable for strengthening your security program.  Some of these less familiar assessments are new, the result of emerging technology and regulations, but others have been around for several years and just haven’t gotten the attention they deserve.  Consider performing these six assessments at least once in your organization to combat the constantly looming hacker threat.

1.       Social Media Assessment

The use of social media sites is rampant.  Would you like to know what is being said on them about your organization?  Assessing your databases and social networks (Facebook, Twitter, LinkedIn, blogs, etc.) detects what is being disseminated on the Internet about your organization – including all of the information that your organization, employees, ex-employees, and the public are putting out there.  In addition, assessing any confidentiality agreements and social media policies you have in place will detect holes in your social media protocol.  This will allow you to integrate effective social media policies into your organization’s overall IT program.

You might be surprised at the large number of existing social media channels through which information is disseminated.  A thorough Social Media Assessment looks at roughly 30-40 of them, including both the well-known sites and some obscure ones such as Hi5, Tagged, Friendster, Bebo, Orkut, Yammer, and Yelp.  In addition, a good Social Media Assessment looks at message boards, online forums, and blogs/micro-blogs like Google Blogger and Tumblr to provide a more complete picture of your organization’s social media posture.

2.       Host Interrogation

Ask security professionals what a Host Interrogation is, and you probably will get more than a few blank stares in response.  The purpose of a Host Interrogation is to identify potential misconfigurations or security flaws on DMZ-based servers.  It provides the insider’s view of servers in much the same way a Firewall Ruleset Review does, which then can be matched up to get more value out of your Penetration Tests.  The Host Interrogation process reviews hardening techniques and best practices in order to establish a baseline, which improves the overall state of security in the DMZ systems.  A good Host Interrogation combines the latest in automated assessment tools as well as a manual review of the overall configurations associated with the DMZ devices.

 

3.       Social Engineering Assessment

Attackers prey on humans’ inherent trusting nature, making the “human network” an easy avenue to gain access to sensitive data or to fully compromise an organization.  The attacker works to gain a level of comfort or form a trust relationship with the individual on the phone, and leverage that trust for an attack.  There are several components of Social Engineering Assessments, to address different ways of prompting a person to divulge information.  Typical assessments utilize phone calls to individuals within a company with the objective of convincing the user to reveal sensitive information.  Originating phone numbers can be “spoofed” to appear to be calling from your phone block, to persuade the individual to download backdoors or to reveal such sensitive information as usernames, passwords, credit card information, salary information, and trade secrets.

Others, like client-side attacks, simulate the main attack methods of the hacking community:  An attacker gains full access to an organization’s network and systems simply by getting an employee to browse a Web site.  Because most organizations’ Internet-facing systems are a high security zone with layers of protection, attackers have shifted their methods and re-focused their attention onto organizations’ employees, taking advantage of human nature and weak security in client-side systems.

4.       Work at Home Assessment

Although telecommuting, or working at home, has been offered by organizations for years, oftentimes the architecture surrounding the remote environment has never been tested.  What an employee does on their computer at home can generate a host of issues that your organization would never face if that employee were in the office every day.  It’s important to test both technical and procedural controls to ensure proper safeguards have been implemented effectively.  For technical controls, there are two primary areas of review:  the remote access architecture including VPN, and the end-user environment including patch levels and other host controls.  For procedural controls, the focus is on reviewing an organization’s Work At Home program policies and procedures.

5.       Incident Response Plan Gap Assessment

When an event occurs that adversely affects the safety and security of your organization’s personnel, systems, and data, a well thought out Incident Response Plan (IRP) is what an organization needs to bring together required resources in an organized manner at a chaotic time.  Most organizations do not have a well-defined IRP that ensures an approved policy is in place to define and address an incident, and that incorporates and tests existing incident response procedures.  During an IRP Gap Assessment, existing gaps within the referenced policies, response methodologies, and accompanying procedures are identified.  Testing such as Attack and Penetration and Table-Top Incident Exercises is strongly recommended to identify any security exposures or threats that are being missed within the current security program.  This methodology ensures the IRP is properly implemented and tested, and correctly follows approved policies.

6.       Privacy Assessment

Although technically not a security assessment, a Privacy Assessment is a critical component of understanding an organization’s risk as it relates to protecting Personally Identifiable Information (PII).  This is important because of HIPAA having more teeth thanks to the Hi-Tech Act, and with the increase in international business and the resulting need for compliance with the EU Safe Harbor framework.  Organizations must have in place a functioning privacy program.

A Privacy Assessment is comprised of a privacy risk analysis, the identification of domestic and international data flows, the assessment of PII safeguards and privacy controls, and the development of a remediation plan and next steps.

Organizations that have undergone a Privacy Assessment - after stating “We’ve got it” or “Our privacy program is working,” are surprised by the Assessment’s findings.  Not only did these organizations not “Have it,” most of them did not even have a fully functioning privacy program.  Whether it was due to outdated policies, non-existent procedures, or a lack of data identification, all of these organizations had gaps in their privacy programs.  Most organizations assessed were in breach of all privacy regulations applicable to them, which could have led to large fines and sanctions.

Stephen Marchewitz is President of SecureState, a Information Security and Privacy Consulting Firm. He can be reached at smarchewitz@securestate.com

 



So I just had a PCI Gap Assessment done and I still do not know where to start. Welcome to the PCI Prioritization Approach

clock June 10, 2011 09:35 by author David Sopata


When an organization is faced with the task of implementing PCI compliance for the first time, it can be very difficult to understand where to start. In most cases, organizations do not understand their scope or the options that they currently have to reduce their scope. Understanding this criteria can save time, money, and additional resources needed to meet PCI compliance. This is where SecureState or another QSA company would come in to perform a PCI Gap Assessment to understand at a high-level how PCI would apply to their current environment. After the gaps are identified, the organization is still stuck with the universal question of “How do we fix it?”

I work with many organizations that have to deal with implementing PCI controls and they always go straight to writing the policies and procedures. I am really not sure what the reasoning is behind this. It may be that writing policies and procedures is the most boring part to them and they want to get it over with right away. Maybe it is because they figure if they write the policy now they can build the rest of their PCI controls and hold to that policy. What really happens is that the policies and procedures end up being changed and revised so many times that it would have been better to write the policy last and describe their environment and what they do. Additionally, organizations will start implementing security controls on all of their systems throughout the company without really knowing what systems should be in scope or which systems should not be in scope for PCI. Hence, the PCI DSS Prioritization Document and Tool was developed.

The PCI SSC (the council) came up with this prioritization approach during the PCI DSS version 1.2. It was meant to help organizations set a starting point, milestones, and provide a high-level roadmap. Granted, even the PCI Council stipulates that this method may not fit within your given organization; however, all requirements must be met for compliance. Not only was the prioritization approach created to give organizations a place to start and milestones to follow, but it was also developed to provide the fastest way to reduce PCI Risk. Just recently in May, the PCI Council has updated the prioritization approach document and tool for PCI DSS 2.0.


So what are the six milestones that council came up with? They are as follows:
1. Remove sensitive authentication data and limit data retention.
2. Protect the perimeter, internal, and wireless networks.
3. Secure payment card applications.
4. Monitor and control access to your systems.
5. Protect stored cardholder data.
6. Finalize remaining compliance efforts, and ensure all controls are in place.

While looking at the order of the milestones, they do make some logical sense. The first one starts with the removal of sensitive authentication data and limit data retention. The goal of this milestone is to get rid of any type of prohibited authentication data, such as the three (or four for American Express) CVV code or full magnetic track data from the credit cards. It might even make sense to delete all cardholder data all together (tokenization anyone?). Maybe there is no need to store cardholder data (CHD) within your organization after an order or transaction has been processed. This would also be the time when a discovery process may be performed to delete CHD from systems that should not have CHD, such as employee desktops, applications, or systems that really do not need to store CHD for any business process. After the unneeded CHD is removed, we can start identifying the systems that are in scope for PCI and start drawing the borders around them.

The second milestone is about drawing the borders around your PCI environment and putting in proper segmentation around your systems. This is where the organization can reduce their PCI compliance even further by segmenting theses systems by using firewalls and router Access Controls Lists (ACL). These firewall and/or router ACLs should be very granular right down to an IP address and TCP/UDP port level. This is how PCI allows organizations to reduce their PCI compliance efforts and make it a more manageable environment. This is also when it would be a good time to start performing security assessments such as Vulnerability Scans and Penetration Tests.

After segmenting the environment and reducing it to only include the systems that store, process, and/or transmit CHD, we can start applying the security controls and hardening techniques to secure these systems. The third milestone is all about securing these systems. This might include turning off unneeded services functions that are used by those systems and standardizing the systems to ensure they are all at some sort of security baseline. Additional vulnerabilities may have been found during the Assessments performed during the second milestone. These will have to be addressed and fixed as well.

The fourth milestone is about implementing logging and monitoring of the systems. After the systems have been hardened, logging and monitoring must be put in place to alert and report on anomalies within the environment. Understanding what “unusual behavior” is within the environment can be a very difficult task to undertake. There are many solutions out there but not knowing what systems are in scope, not having proper segmentation in place, and not turning on the proper logs for the systems could make this area costly and ineffective by wasting time, money, and resources. Additionally, trying to control access can produce the same effects without knowing what systems are in scope and knowing the capabilities of each system.

After securing the systems and implementing logging and monitoring, it is time to then start securing the data that resides on the systems. This is what the fifth milestone is about, ensuring that the CHD that is required to be stored is also protected. This includes implementing proper encryption and key management processes for the systems in scope. In many cases, key management tends to be the hardest area that most organizations struggle with when it comes to encryption.

Now comes the final step, documenting what you have done. The sixth milestone is about Policies and Procedures and making sure that you have all of them in place. Additionally, like any methodology, there might have been a few road blocks where something had to be skipped to keep the project moving. This is where you would tie up any of those additional “loose-ends.”

Whether you are just about to implement PCI in an environment or in the middle of a PCI implementation project, it might be time to take a step back and ask “Am I following the right approach?”