LearnSecurity Blog

Home
About
Services
- Audit
- Tax
- Accounting
- Information Systems
- PCI Services
  - PCI-CP
  - PCI-WAS
  - PCI FAQ
  - PCI-CS
  - PCI-CR
  - PT
Qualifications
Resources
Careers
Contact
- Map

Who told everyone it is a good idea to start a security initiative with White Hat hackers doing a blind penetration test on your network? Or does it just sound cool and impressive? Or is it really getting the cart in front of the horse.

I often see RFPs that ask for blind penetration tests. I wonder if they know what they are asking for. A blind penetration test will require us to blindly find vulnerabilities and then exploit those vulnerabilities to prove that a hacker could breach the system. There is a time and a place for this type of assessment. It however, is not the best assessment to have right out of the gate.

Let look at some semantics.

Vulnerability scan is an assessment, usually non-intrusive, non-destructive scan of a set of systems to determine if any vulnerability can be discovered by the scanning service or device.

Penetration test is an assessment that is intrusive by nature. It starts with a scan to determine what vulnerabilities exist. It then will try to exploit the vulnerabilities. By its nature the scan is intrusive and potentially destructive.

A blind test can be either a penetration test or vulnerability scan where by the assessor does not know the addresses of the system to scan. A determination is made as to what the addresses could be and scans are then run against those addresses.

Pros and Cons

Vulnerability Scans

The pro, vulnerability scans are a must. Especially if you process payment cards as vulnerability scans are required by the Payment Card Industry Data Security Standard (PCI DSS). They are a common control in just about every other industry standard from NIST to ISO. Vulnerability scans give you view of what vulnerabilities a potential hacker could see. Generally the scans are run from a device that is outside the firewall, from the Internet.

The con, whiles these scans provide a great picture of how an external hacker sees the system they do not paint a good picture of what vulnerabilities actually exist beyond the firewall. This is because the firewall is doing what it is designed to do, which is limit what access is granted from the Internet. However, the firewall does not generally protect form malicious internal users or malicious code that gets past the firewall. In order to get a complete picture we recommend external scans and internal scans of the Internet facing systems. In this way the organization has a complete picture of their vulnerabilities and can make risk based decisions.

Penetration Tests

The pros, penetration test allow an organization to see and know that the vulnerabilities can be exploited. Most external attacks require hackers to 'hop' their way in. The will compromise one system, hop from that system to compromise another and so on. A vulnerability scan will not confirm the vulnerability exists or that they can be exploited. A penetration test is proof that the vulnerability exists and can be exploited.

The cons, because the test exploits a found vulnerability it intrusive and potentially destructive in nature. The question remains do we need proof that the vulnerability can be exploited? Is it worth the risk a damaging or bring down a system to prove that a vulnerability is exploitable? Most of the known vulnerabilities have been tested, confirmed and indexed.

Blind Tests

The pros, the assessor does not have all the information so you get a good indication of what a hacker would be able to find if the hacker was only targeting that organization.

The cons are the blind test is really testing the ability of the hacker to find systems. Many hackers don't target a particular organization they simple sweep the Internet looking for vulnerable systems. Second, a blind test is really testing 'security by obscurity’; a security mind set most security professionals avoid. Just because you don't see a vulnerability does not mean it does not exist.

In addition, a blind test could lead the assessor to scan a system that is not owned by the organization and could lead to ethical or legal issues.

Recommendation

I recommend that an organization start with adopting a security standard and conducting regularly scheduled vulnerability scans, internal and external. All the major standards require at least the following IT controls, patch management processes and vulnerability management. To simply test systems in an ad hoc fashion will not improve non-existent controls. If you don't have a process, every assessment you perform will indicate that you have vulnerabilities, which in turn just means you don't have a process.

Donald E. Hester

CISSP, CISA, CAP, PSP, MCT, MCITP, MCSE Security, MCSA Security, MCTS, MCDST, Security+, CTT+, MV

Brought to you by Maze & Associates, a leading Northern California Accounting Firm specializing in Municipal & Nonprofit Audit, Tax for individuals and all types of entities, Information System Audits, Security Reviews, as well as PCI Scans and certified training. Maze & Associates is a PCI ASV - Approved Scanning Vendor.

RSS Subscription: http://feeds2.feedburner.com/learnsecurityblog

Disclaimer: The views expressed here are those of the author and do not represent those of Maze & Associates.

New Presidential Cyber Security Initiative

Today President Barack Obama presented a 10-point near-term action plan aimed at securing the federal government's and the nation's critical IT infrastructure. Why? Because "Acts of terror could come from a few keystrokes."

The 10 steps outlined are:

1. Appoint a cyber security official

2. Setup a national cyber security strategy

3. Make it a priority

4. Come up with a privacy and civil liberties official

5. Set up interagency mechanisms (Government teamwork)

6. Create national public security awareness program

7. Develop international collaboration (International teamwork)

8. Create a national incident response plan

9. Support research and development

10. Create a identity management system (keeping privacy and civil liberties in mind)

President Obama's final remarks, "But we need to remember: We're only at the beginning. The epochs of history are long - the Agricultural Revolution; the Industrial Revolution. By comparison, our Information Age is still in its infancy. We're only at Web 2.0. Now our virtual world is going viral. And we've only just begun to explore the next generation of technologies that will transform our lives in ways we can't even begin to imagine."

You may remember form one of my previous post that the National Cyber Security Alliance is working on raising awareness and literacy of information security. This works hand in hand with point 6 of Obama's new initiative.

The real question now is what is to become of the current information security landscape. I have a few ideas of issues that should be addressed.

1. Simplify legislation. Currently we have different sets of rules for different sets of date. SOX, HIPAA, Breach Disclosure and other laws can be simplified and combined. Why have one law for financial date (GLBA), one for health data (HIPAA), one for student data (FERPA), one for financial reporting (SOX) etc.. Create one law that covers personally identifiable information (PII) and data integrity regardless of type.

2. Continue to raise awareness public awareness.

3. Address jurisdictional issues with Internet based crimes.

4. Create incentives for business to 'do the right thing' positive and negative reinforcement.

5. Take the bureaucracy out of FISMA.

6. Extend a new FISMA to state and local governments. Extend the funding needed to implement for the state and local governments. State and local government maintain part of the infrastructure. The infrastructure is only as strong as the weakest link.

7. Understand security is a process not a goal.

8. Ensure security is implemented in a risk based fashion.

9. Protect privacy while protecting the infrastructure.

There are probably 100 other things that can be done. These are just a few that are top issues in my mind.

Donald E. Hester

CISSP, CISA, CAP, PSP, MCT, MCITP, MCSE Security, MCSA Security, MCTS, MCDST, Security+, CTT+, MV

RSS Subscription: http://feeds2.feedburner.com/learnsecurityblog

Disclaimer: The views expressed here are those of the author and do not represent those of Maze & Associates.

Will security metrics solve the issues with FISMA?

Will metrics solve the issues with FISMA? Federal CIO Vivek Kundra is betting metrics will help improve efficiency. (I know government efficiency sound like an oxymoron.) The OMB has reported the 20 out of the 24 federal agencies have significant deficiency or a material weakness in their information security programs. Kundra feels FISMA has is compliance based on not indicator based. Imagine that, the government took a perfectly good framework and turned it into a bureaucratic paper exercise.

Kundra has it right when he said. "We will never achieve our security goals through compliance alone because security threats are fluid and constantly changing." Margaret Graves, acting chief information officer of the Department of Homeland Security, supports FISMA but still echoes Kundra point when he said, "What is also apparent is that simply maintaining a controls framework alone is not enough."

The NIST Certification and Accreditation (C&A) framework developed for FISMA is a risk based process. Well, that is the intent at any rate. The problem with the implementation of NIST standards by government agencies is the tendency to view it as a 'check box' exercise and not an ongoing dynamic risk management process. How do we know this is the problem? Look at the required documentation for C&A. You will find in the forms a risk management document for any given system. It most likely was copied from a previous risk assessment from a different system, before implementation of the system and not updated until the recertification of the system. Not only that, the forms used are cumbersome and confusing. What most end up with for their risk management program is a static risk document that has no direct correlation to the controls in place or the current risk environment.

The problem is not exclusive to the federal government you find organization that use ISO doing the same thing with risk management. Insanity is often defined as doing the same thing over and over expecting a different result. If we continue with our static and isolated risk management process we will not change anything.

One of my favorite examples of this insanity came from a recent discussion concerning control implementation for a system of lab computers that are connected to a network that is not connected to any other network. The network and lab computers are completely isolated from any other network and thus also the Internet. During the C&A phase the system owner determined the baseline controls and started to implement those controls. One of those controls was a firewall. The question I asked staff was "What threat was the firewall meant to protect this isolated system from?" Can you see the disconnect? They were blindly implementing controls without regard to actual risk!

What is the solution for this apparent dilemma and insanity? The risk management process must be directly tied to individual controls in such a way as to be dynamic and useable. This process requires the risk management documentation and control implementation documentation (system security plan for NIST folks) to be linked. This is difficult to do, using the current method most people use, which is a document format. A database is much better suited for this task. You can than have a many to many relationship between your risks and your controls.

Risk management must also be an ongoing process. Risks change daily as threats and threat agents change. It is safe to say that your risk changes daily, if not more often. The disconnect with many current risk management processes is the risk is reevaluated annually or less often. Is it enough to reevaluate your risks only when you have major changes to the system? The question in response is, does risk only change when there is a major change to the system? No. Risks change more often than major changes to the system.

We can have all the metrics in the world. If we don't have a dynamic, realistic, easy to use risk management system the metrics will only indicate we are do not have an efficient information security program. It is the only way we can address security threats that are fluid and constantly changing.

Donald E. Hester

CISSP, CISA, CAP, PSP, MCT, MCITP, MCSE Security, MCSA Security, MCTS, MCDST, Security+, CTT+, MV

RSS Subscription: http://feeds2.feedburner.com/learnsecurityblog

Disclaimer: The views expressed here are those of the author and do not represent those of Maze & Associates.