Slashdot Mirror

The security testing world actually has a pretty good methodology behind it now.

Check out the Open Source Security Testing Methodology Manual (OSSTMM) from the Institute for Security and Open Methodologies (ISECOM)

I gravitated towards ISECOM's OPST/OPSA classes because they fill a role I felt was missing in the security class space. Many non-vendor specific security classes have a very narrow tools based focus. While I agree that knowing how to use your tools in a test is important, I feel knowing why and when to use them is far more important. Knowing the politics involved in testing, going over internationally accepted testing practices, and reviewing regional and national legal regulations are just as much part of the job. These things are not merely important, but are required to be successful in your role as a security tester. In addition to the intensely technical aspects of the testing process, this is what the OPST represents; the "professional" side of security testing. Also, the ISECOM classes teach from ISECOM's Open Source Security Testing Methodology Manual (OSSTMM) which provides a much needed methodical framework to bring a scientific method style to the chaotic world of security testing.

The CEH class represents the other kind of class. One that is "flashy", "fun", "exciting", but not overly useful to the serious professional. While I have a lot of respect for Clément (one of the instructors for Intense School), I have very little respect for any organization that markets "hacker" classes. This includes the so-called ethical hacking, applied hacking, exposed hacking, grandmother hacking, squirrel hacking, super-duper 3y3 4m 31337 hacking, or any other fancy way of saying "Learn how to think and act like the bad guys".

While choosing where to spend your time and money, consider the community you are aligning with. If you look at ISACA, SANS, ISC2, ISECOM, etc.. they all have a true dedication to security and the betterment of the global information security community. Contrast the value of being affiliated (via education/certification) with any of those organizations over a piece of paper and a cd of toys.

It may sound like a problem that the book doesn't give all of the details, but if it did there is no way it could be a "Portable Reference". My favorite feature of the book is its small size. I can easily keep it in my laptop bag and reference it as needed. I can then use that as a springboard to look up more information such as man pages. It is important to understand though that one will not become a network security expert after reading this book alone.

The book starts off talking about the Asset and Risk Based INFOSEC Lifecycle Model (ARBIL). This is something that I've heard many times before, but the drawing of the process helped engrain that concept. It also visually demonstrates how security is not just a one-time activity, but a continual process that just keeps going. You analyze the system, find the weaknesses, fix them, and then start over again. In the same fashion the book covers the SMIRA risk assessment process in a highly graphic way.

The Network Security Portable Reference is for people who have access to and are very familiar with both *nix systems and Windows. Depending on what tool or commands they are using both systems are used throughout the references. The book gives a list of tools they think you need, and basically say go to the site to learn about it. If you want detailed information on how to use these tools then this is not the book for you.

The book goes over different security aspects for *nix and Windows machines, it also talks about how the network itself can be compromised, including wired networks, and wireless. The authors also go over web applications and older technology such as phone PBX systems.

The assessment checklist at the end of the book provides a great check to determine your network security baseline and see what areas need work. Along with the assessment checklist there is a list of best practices. However, they are in the front of the book and while I can vaguely understand the difference, it seems to me that they should be together. As I believe when auditing a network you would check if best practices were implemented along with the rest of the checklist.

Another odd layout issue in the book is what they call the Reference Center. This is an area in the middle of the book, with a separate numbering system and the first page in the table of contents. There is no mention as to what this Reference Center is until you flip through the book and find the blue pages in the middle that begin with page rc1.

As I've mentioned before this book is a great springboard that will help point you in the right direction for information. One of the ways the authors do this is by having a Reference Center in the middle of the book and quite a few appendixes in the back of the book, there is also an index which is helpful for quick look ups.

When doing consulting work I've found that using the checklist in this book is a great way to begin looking at a company's network security. I have used this on two networks so far and have found it helpful, it is much better then trying to remember to check everything that you can think of at any particular moment. I have also found the Open Source Security Testing Methodology Manual to be quite thorough.

What you'll find is people really defend to the death what they think is security based on how much they *really* know which you'll find is usually about the level of what they read in Computerworld magazine. Even the self-proclaimed experts. You are best off doing what you can, even if it's just scanners, but realize it's not exactly a definitive or even realistic test of security. But it is something and worth doing. Remember to keep it practical and most of all, make sure you can measure it. One problem with a lot of these scanners and semi tests is that they give you some arbitrary high-medium-low talk. Try to put real numbers in there so you can actually measure risk. For more details on practical testing with risk measurement is in the Open Source Security Testing Methodology Manual and a lot of information over at the Institute for Security and Open Methodologies. Inform yourself better and with ISECOM you can at least know it's a lot of information from many many security people (800+) giving peer review.

All I can say is that I see this problem often enough where a security consultancy is threatened by their client because their portscan which was done during a valid Internet security test has brought down an important system. Realistically, if something like a portscan can bring down a system then that is a real problem. You know how much random garbage comes across the Internet that can cause a similar problem?!

If the monitoring is happening so as to cause a DoS, which appears to be the case, it's an availability threat to your customers and a security threat to you. Since you provided no details on the type of monitoring and specifically how they did it, it's not possible to advise specifically. For example, if they use ICMP, there is a very good possibility that you should have been dropping silently ICMP of all types coming through your gateway router. That is considered best practice for security.

Treat this like a security issue and make it go away like a security issue. That implies using technology controls and policy to clean up this mess. In your case, policy will also include a letter from your lawyer and providing your customers with the uptime data they require.

-pete.

-- You bought all that security for your network, maybe it's time you got something for free. Like the ability to test it. The OSSTMM at www.osstmm.org - Stop talking security and start doing it.

While this book does an excellent job in detailing how to implement a solid security environment, it falls short of providing how to test the security of an environment.

There is an open source project methodology that would be a great additional read for the purpose of testing the security of your environment. Go check out the Open Source Security Testing Methodology Manual (OSSTMM). They just released the 2.1 version of it as described here.