Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique





















Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Keross: Why Doing Penetration Tests ?

February 2010 by Keross

“Are you sure we closed the window ?”
You know the scenario. You’re halfway to the airport, and suddenly your partner says, “Are you sure we closed the window? I don’t want to worry about burglars throughout our holiday.” And you’re sure. Really sure. Well, 99% sure. Should you turn back and check? No, that would be paranoid. It’s all right. Probably.

CEOs and IT managers will be familiar with the feeling. Is our online sales system really secure? What about the personnel files? The financial data? Might hackers find a vulnerability? Might internal staff see more than they should? Are there backdoors for convenient maintenance that one person too many knows about? There can scarcely be an IT manager in the world who hasn’t put a lot of thought into security. And yet there can scarcely be a manager in the world who would really stake his life on it being foolproof.

Hacking our own systems: the snag

As a result, an entire industry has grown up around security checking. But there is an immediate dilemma. Do we go outside to some unknown firm and ask them to try to hack into our security? What if they find a loophole? Will they tell us, or use it against us? What if the tests themselves cause damage? So perhaps we should do the tests internally? But if we think about it, internal IT units are actually the least suitable people to test their own security. If there is a problem, it’s because there’s some aspect we haven’t thought of. By definition, we are less likely to think of it now than someone coming fresh to it.

A balanced solution

So it does make sense to go outside for the test, but you need a partner with an established reputation and a well-defined test that you can trust. Because Keross manages systems for other companies, we considered this early on and have developed a precise protocol.

1. Definition of the risks to be tested. The most common risks are:
• Technical weaknesses (hackers, accidental exposure)
• Lack of secure governance (lax internal procedures)

2. Definition of the tests to be made.
• Technical weaknesses are addressed by a 3-step process, to answer the questions:
1. Can the IP, operating system and other software be identified?
2. What systems and services of your company can be identified using that software and IP address?
3. Is it possible to crack the security of any of those systems and services, focusing especially on data transfer between systems?

• Governance issues
An ISO 27001 audit is conducted. If the organisation is already complaint with this, the audit is to test this. If it is not yet compliant, the customer is taken through the steps to achieve it.

3. Carrying out planned “attacks”
We will propose specific “attacks” on the system, simulating hacker behaviour, with well-defined possible effects (e.g. that a particular data item can be inspected, inserted, removed, or changed. This is done in cooperation with the internal IT department with a KEROSS technician on the spot. Not all attacks are surreptitious. We can also test for ‘brute force’ attacks. What if your company acquires an enemy, perhaps a former employee with a grudge? Can your systems be brought down by denial of service? It is absolutely essential that all such tests are done in a planned way, with known impact. We will never make any intrusive test without explaining the scope of the potential impact and getting the customer’s explicit agreement.

Testing the authentication system

The lone teenage hacker in a back room is not the most common risk: most security breaches are due to loss of secure authentication. We will study how opaque your system is: how far can an outsider determine how people identify themselves? Because we specialise in the area, we are able to advise on whether your procedures are “state of the art”. If there is a trade-off between convenience and security, how much risk are you taking if you make authentication a little easier? The objective is not to make everything difficult, but to give you transparency on where any risks exist and what actions you can take.

The bottom line

The result should identify for you how your risk profile compares with the industry standard in:

• System security
• Services configuration
• Image protection
• Filtering policy
• Application layer security
• Overall opacity

The cost of doing this sort of security audit is low: this is work we do regularly, so we can do it in a fast and well-tested way. The benefit is assurance for you, and for your customers who work with you. Not to catch the IT department out, but to provide independent confirmation that everything has been covered. Yes, you really did close the window. Or – perhaps – that you closed the window you knew about, but there is another window which the latest techniques can detect – and that needs to be closed as well.




See previous articles

    

See next articles