Saturday, December 5, 2009

Appendix A Professional Security Testing

Introduction

Sometimes you win. Sometimes you lose. Sometimes it's all about the game. Security testing is all about the game. Without trying to borrow too much from sports, it's really about being in the zone. It's when the data reveals itself to you smoother than silk on silk—all systems roll out in front of you like that all-inviting red carpet and while you stroll down the line, doors pop open every­where you look. As you glide into the final stretch, you look back and all the weaknesses of the entire security presence are lit before you, perfectly structured in a pattern like the lights of an office tower after dark.

Sometimes though, it's like being stuck in a Dr. Seuss book with all sorts of bizarre characters, roads that fold back on themselves, and doors floating in the sky that go underground.The path becomes a labyrinth, and your way is easily lost as all your tools begin to fail.You follow the westward descent of the sun only to find that upon turning around, all that was visible is now blocked by your own shadow.

It's all about the game. Hide and go seek is one of those games we play because it's fun with its elements of surprise and stealth. As you get older, the game becomes a balance of speed and escape for most players and much less about actually hiding. Can I hide well enough that someone else will get caught before I am found? Who else has seen me use this hiding space so it's no longer good when it's that kid's turn? Can I hide close enough to the base that I can get safe before I get tagged? Can I position myself in a lesser hiding place but where I have more than one escape route?

Of course, little of that is consciously decided.The kid picks the position that most reflects his or her ability compared to the person who is seeking.Those who choose wrong are caught. Those who choose right go free. Then everyone re-evaluates possible hiding places after each round. Meanwhile, the seeker has to analyze all the possible strategy changes simultaneously. Each time a kid seeks, he or she realizes that experience for that game counts very little. Each hider will most likely take new strategies and the ones who don't, won't, because they cannot be caught anyway. The game continues.

Security testing is that game where the tester is the seeker. Each round brings more data, even if the data is false or empty from no response.The tester must make a decision each round whether to keep going with that direction or pick a new strategy. Each hider that can be caught must be caught. Those who have excellent strategies are noted in case later we realize that the elapsing of time has

eroded that particular strategy. The strategies are based on the operating systems, the network architecture, the available services, the business processes, and even the people. The game is played out until everyone is caught or until time runs out. Just like in real-life hide and go seek, there is no quitting while you are still the seeker. But unlike the real hide and go seek, being a bad seeker can have drastic consequences. If a security tester does a poor job, it could mean the client loses money and the tester has the liability. It can also mean—as in the case of security testing high-frequency microcontrollers in motor vehicles—that people die and the tester is then held liable.

So it's no wonder that security testers have a love for search engines like Google.To us, the security testers, Google can be the source of facts that have spilled onto its ever-growing cache in the moment it takes us to blink. Facts do not require that the information be true, only that the fact is there and that it came from a particular place at a particular time. Google is also comprised of knowledge, experience, and the stupid mistakes of thousands of other security professionals that we can compare our own work to. It's an up-to-the-minute reference library that doesn't exist yet in any other form. Unlike a mailing list or forum, it answers our questions because of how and when we ask them. It doesn't judge us as to why we asked them.Therefore, our fragile egos won't be bruised or shattered.



Professional Security Testing

It is true that hacking, in the security sense, is an art. The current services in pen­etration testing and ethical hacking require skills of intuition and creativity. Most often, the decisions made and avenues followed in hacking are instinctual and follow a simple methodology that provides great freedom. Like any art form, whether a thing of beauty or a message, the creation is a combination of the hacker and the effort. But this is not professional security testing.

Performing security testing in a professional manner is to be a researcher and a detective. While there may be some art to it, the amount of intuition or expe­rience you have is indirectly proportional to the valid results you achieve. While a great hacker may also be a great security tester, the primary skill set of the security tester is the same of any researcher, knowledge and persistence. Valid results, which must be verified and understood, are the holy grail of a security test. Hacking, just as in any art, is about the final creation. In the end, it doesn't matter what you did to create that art, just that you did it and it's impressive.

Security testing is about being sure of everything you did to reach the end result and understanding why you did it.You need to understand the conclusions you have reached and find as much evidence as necessary to support those conclu­sions. The final results may or may not be impressive, but either way they don't require an artist to create them.They require a methodology.



The Open Methodology

In December of 2001, a Google search for either a security testing methodology, a penetration testing methodology, or an ethical hacking methodology all brought back the same phrase. Regardless of the Web site, the phrase looked something like this:

"...The best possible test using our in-house, proprietary method­ology for security testing..."

This phrase, while deceptively boilerplate, indicated a devastating flaw in the art of the security test. In-house proprietary methodology loosely translates to "we did it our way, and we can't tell you what that way is; it's proprietary." For this reason, the Open Source Security Testing Methodology Manual (OSSTMM) concept took off. Hundreds of people contributed to the project, injecting both criticism and encouragement. Every piece of feedback made it better. Eventually, as the only publicly available methodology that tested security from the bottom up (as opposed to the policy down), it received the attention of government agencies and militaries around the world. It also scored success with little security start-ups who wanted a public source for client assurance of their security testing services. Now, the OSSTMM seal, as seen in Figure A.1, is the standard for secu­rity testing reports, accepted internationally by most all government auditing organizations.

Подпись: Figure A.1 The Generic OSSTMM Seal
The OSSTMM had been housed under the domain ideahamster.org, where it received a steady amount of traffic from contributors dubbed as ideahamsters, a nickname for people who were currently churning out new ideas like a hamster on a wheel. However, as the OSSTMM grew in popularity, the organization and its name were pressured to grow up as well. In November of 2002, ideahamster announced the name change to ISECOM, which actually stood for the Institute for Security and Open Methodologies. By January 2003, ISECOM had been registered as a non-profit organization in Spain and the United States. Now it officially belonged to the people. And the users of the OSSTMM had a responsi­bility to give back to it or else it would cease to exist.

As the OSSTMM continues to grow, it has never lost its vendor-free, industry-agnostic, politically clean values. The methodology has continued to provide straight, factual tests for factual answers. It includes information for pro­ject planning, quantifying results, and the rules of engagement for those who will perform the security tests. As an academic document, it's a flop. It is full of gram­matical errors, the English language shifts between British and American spelling styles, and the format is unacceptable for most every university graduate pro­gram. However, the goal of the document is not academic. It is simply there to be used. The OSSTMM has no intentions of being a textbook. As a method­ology, you cannot learn from it how or why something should be tested. What

you can do is incorporate it into your testing needs, harmonize it with existing laws and policies, and use it as the framework it is to assure a thorough security test through all channels to information or physical property, as seen in Figure A.2, a map of the security presence.

Figure A.2 Map of the Security Presence with All Channels for Access to Information and Physical Property

The security presence is the area for which security can influence your property regardless of your ability to influence or practice security therein. For example, consider protecting your ice cream shop from theft. There are many ways an attacker can cut the electricity going to your store. While that isn't stealing your merchandise, it adversely affects your product line (your ice cream melts) and therefore reduces your income. Is the electrical grid within your security pres­ence? Yes. Can you directly control it? No.You have to rely on service-level agreements from the power company and buy your own generator to handle brownouts and blackouts. Electricity is considered part of physical security, which is just one channel of five that make up your security presence. It gets even more

complicated as technology promotes channels to cross. The five channels are described in Table A.1.

Table A.1 The Security Presence Channel Descriptions

Channel Description

Personnel Comprises the human element of interaction where

people are the gatekeepers of information and phys­ical property.

Physical Comprises the non-human tangible element of secu-

rity where interaction requires a physical effort to manipulate it.

Telecommunications Comprises telecommunication networks, digital or

analog, where interaction takes place over estab­lished network lines without human assistance.

Wireless Comprises all non-human interaction that takes

Communications place over the known communication spectrum,

from the lowest frequencies to the highest.

Data Networks Comprises all data networks where interaction takes

place over established network lines without human assistance.

Understanding the extent of a security presence and the concept of security channels requires a certain amount of research. Often times,the depth of this research is dictated by the amount of time allocated, which reflects on cost or price. Even the smallest amount of time wasted, whether through inefficiency or inability, can have drastic consequences like in the case of securing a Red Cross barracks on battle-heavy soil, where wasted time means people die. While today's standard penetration tester doesn't have that worry, don't doubt that the future needs for security testing don't have that vision. This all points to the need for a standardized methodology for security testing.

The Standardized Methodology

In the plainest terms, a methodology is a structure.Think recipes from a cook-book.The methodology is the difference between a cake and just a big mess of ingredients. While there are many different types of security methodologies, there is only one that's universally accepted for security testing and the quantification of metrics.

The OSSTMM is a standardized methodology for a thorough verification and measurement of the current operational, security state. That's actually a lot of academic-type talk for saying that the OSSTMM will aide you in performing a security test according to a recipe that allows you to not only run the best pos­sible test you can generate in the most efficient way (saving time saves money), but that also gives you numbers that realistically represent your current level of security.

Actually, the OSSTMM will define and quantify three types of security within the chosen scope. This is an important concept because the scope may not be the same as the security presence.You can think of the scope as the working space for a project from the vantage point of where you will do the work. If your project is to test a company network, then the scope may be all systems from the vantage point of the internal network. Or it may be the scope of all the systems which are Web servers. However, both scopes are subsets of the security presence that make up the entire environment in which those two chosen scopes reside. Once you have defined a scope, the security tests and metrics are con­strained to that scope and the assets within that scope. Obviously, this, like statis­tics, can help you see only what you want to see. Like the old joke where a lady sees a man looking for his car keys at night under the street lamp. When she asks him what he's doing, he tells her he's looking for the keys he lost on the way to his car. She asks if this is where he thinks he most likely lost them, he answers, "No, but this is where the light is."

Of the three types of security quantifiable through the OSSTMM, the first type, which we define as Operational Security, is actually the lack of security you must have to be interactive, useful, public, and open. Think of any store. It has doors, sometimes windows, a lack of clocks on the walls, conveniently spaced aisles that encourage you to walk down them, and a door with a sign telling you that the store happens to be open. Why? Because it generates business having you there. The store needs to be insecure enough for you to walk in the front door so you can pick up items and put them in your basket. For that store to even exist it needs to have people come in and leave money. Before any other security requirements are considered, the store needs to be in operation. Operational Security is measured by calculating the following parameters during a security test:

■ Visibility For the scope you have defined, how many of those gate­ways to the assets (in fact, the gateways themselves may be assets), whether they are computers, people, windows, or telephones, can be

determined to exist from the perspective of the test? In the example of the store, from outside the store how many employees can I determine to be inside the store with certainty? I want to know this because what­ever is inside I may try to interact with (or attack or manipulate or cir­cumvent...). Perhaps I can even determine through interaction which employee is carrying the keys to the registers.

■ Trust For the same scope, how many of the gateways to the assets allow for non-authenticated interaction either between each other or with the outside? In a small store, the employees will authenticate each other continuously just because they recognize each other according to their faces. In a large company, how do you know who is a fellow employee? By their badge? It's the same with computers. Does the Web server move data to the database server without ever having to authenti­cate itself?

■ Access For that same scope, how many actual areas are there where I can get interaction through a gateway? This is different from visibility where we are determining the number of gateways that are there. In vis­ibility, you only count each gateway once regardless of how many dif­ferent ways we can know it's there and regardless of whether it interacts. Where in visibility I may count that big, iron back door because it is a door that could lead into the store, I would only count it under access if I could get someone or something to interact with me when I knock on it. Additionally, I count all the different action/interaction scenarios with that door. If I knock and someone tells me to go away. That counts as one interaction. If I pick the lock and the door interacts with me by swinging open, then I count that as a second type of interaction, with the easily picked lock also classified and counted again in the second type of security.

The second type is defined as Actual Security .This type is when we take into consideration that operations require a lack of security, and that anything which is open, trusted, or interactive beyond what is necessary is a problem. Consider a movie theater. While doors must be open to have customers come in, a back door with a badly designed lock where people can easily pick it to sneak in is not nec­essary for business. It's actually anti-operations since too much sneaking-in will inevitably lead to the end of operations. So, beyond what must be open, a security test has to tell us what is just not working in the current state of security.There following five classifications of Actual Security are called security limitations:

■ Vulnerability This is defined as a perceived flaw within a mechanism that allows for privileged access to assets. By "privileged" we mean that you can do something with them or to them. A vulnerability may be a metal in a gate which becomes brittle below 0° C, a thumb-print reader which will grant access without a real thumb, a mail server that lets you send SPAM to anyone you want, or even that employee who wedges the back door open all day to conveniently slip out for smoking breaks.

■ Weakness A weakness is any misconfiguration, survivability fault, usability fault, or failure to meet stated security requirements whether they are law or just policy. A weakness may be a process which does not save transaction data for the legal time limit as established by regional laws—for instance, a fire door alarm which does not sound if the door is left open for a given amount of time, or a firewall which allows enu­meration of internal systems using specially crafted TCP packets.

■ Exposure This is defined as a perceived flaw within a mechanism that allows for unprivileged access to sensitive information concerning data, business processes, people, or infrastructure. It's generally used to gain privileged access or even just further knowledge on the operational security state. An exposure may be a lock with the combination available through audible signs of change within the lock's mechanisms, a router providing SNMP information about the target network, a spreadsheet of executive salaries for a private company, or a Web site with the next review date of an organization's elevators. Exposures are often called "information leaks."

■ Concern This is any security uncertainty for which a visible gateway or interactive access point provides neither privileged nor unprivileged access and has no clear business justification.This can include everything from a secretary who gives out the direct phone number of certain exec­utives who never answer their own phone anyways to the system admin­istrator who has their resume online disclosing the skills learned during their current job, but that contains no specific system, network, or per­sonnel information. Just the ability to see the papers on an employee's desk through the window will be a concern, even if the papers do not currently disclose information or increase access capabilities.

■ Anomaly Any unidentifiable or unknown element that is a response to the tester's stimulus but that has no known impact on security. This is

data that tends to make no sense and serves no purpose as far as the tester can tell. It is reported solely for the reason that it is a response which can be triggered and may be a sign of deeper problems that may be inaccessible to the tester. An anomaly might be an unexpected response, possibly from a router in a network, that may indicate network problems. An unnatural radio frequency emanating from an area within the secure perimeter, however, offers no identification or information; the same is true for a phone which rings three times and then whistles. Additionally, it is up to the tester to be certain the anomalies come from the source in question and not from misuse of the tester's own tools.

Furthermore, these classifications are divided between verified and identified security limitations. It is the responsibility of the security analyst to verify all security claims reported. However, not all claims can be, or should be, directly verified. For example, an analyst who determines that the company has a single ISP and a single router is vulnerable to drastic Denial of Service if that router is taken offline.This is categorized as an identified weakness. To escalate it to a verified weakness, the tester would have to actually attack the router in a way that would prevent service for the rest of the network. The difference between verified and identified in the security test is about a level of factual certainty. However, the loss of business that this Denial of Service would cause the company is a value far greater than the liability the security tester can afford for reporting this falsely. Therefore, the security analyst can be confident in the decision that having more certainty a Denial of Service will be the result of this single point of failure is acceptable and preferable to the alternative.

The final type of security the OSSTMM defines is loss controls.This is actu­ally defined as ten practices that prevent loss as opposed to performing security. While some of these may appear to be security to most of you, keep in mind that they don't actually prevent interaction with, or visibility of, access gateways. The purpose of loss controls is to assure that assets, such as data or even the access gateways themselves, are protected in the case of theft, failure, or any other type of loss. While you may recognize all of these loss controls and consider some of them weak or worthless on their own, few perfectly controlled systems apply all of them.The main reason for loss controls at all is to protect your investment in your business and the interests of those you want to do business with. Consider setting up shop to take credit cards. Neither Visa nor MasterCard are interested in how many robbers break in through your flimsy doors or poorly constructed Web site and steal your assets.They just better not be able to steal

theirs. So Visa, for example, applies a security audit to assure that even if your production server walks out the door, that list of customer credit card numbers on it defies loss. It should take the attacker more resources and time to get those assets from Visa than they are worth. We've all seen the movie where the bank robbers have a really hard time breaking into the main vault only to find that their techniques burned up all the cash inside.Those are loss controls. And they're classified in the following manner:

■ Authentication What are the requirements (or barriers, to those without authentication) to enter through the gateway? If I ask you for your passport before allowing you to enter to your gate, I am authenti­cating you.

■ Non-repudiation What exists to prevent the assumed source from denying its role in any interactivity regardless of whether entry was obtained? If I can back up an e-mail sent from your computer with time-locked videotape of you sitting at that computer composing the mail, then I am producing non-repudiation of you and your actions.

■ Confidentiality Is the information or physical property displayed or exchanged between two parties known only to those two parties? If I see you exchange a closed, plain-paper package with a colleague, who views the contents of the package without revealing them to you, that interaction occurred with a high degree of confidentiality.

■ Privacy Is the way that information or physical property is displayed or exchanged known only between two parties? If I know that you're going to present your friend with birthday balloons and you enter into your friend's home with the balloons and I can't see or follow the inter­action process to know if your friend is happy with the balloons or indifferent, then you interacted privately.

■ Indemnification Is the gateway as an asset or the information or physical property protected publicly by law or privately by insurance? If you hit my car, I may be able to legally demand money for repairs from you. If I can't find you or make you pay, then my insurance will cover the damage and perhaps pay for a rental car so I don't lose productivity while waiting for repairs.

■ Integrity Can the information or physical property be changed or exchanged without all parties involved with the assets being aware of

the change? If you swap out my regular, brewed coffee with an instant one made of freeze-dried flakes, both of us would need to be aware of the exchange for me to say that I have strong integrity with my coffee.

■ Safety Will the security processes or mechanisms fail, but the protec­tion provided does not fail? If you cut power to a bank in order to break the electromagnetic conduction holding the lock in place on the vault, which in turn forces the lock to drop a wedge making the door impossible to open until power is returned, then we can say the lock failed safely.

■ Usability Where protection is interactive with the accessing party, do decisions of the protection process require the action of the accessing party? In order to have you to send a confidential e-mail to me, you need to use encryption. By default, the mail is not confidential and con­stantly requires you to remember to encrypt the e-mail. For this reason, we can say that your e-mail fails the usability test for security.

■ Continuity Can interaction with, or through, the gateway halt interac­tions or deny intended interaction upon failure of the gateway? As a store manager on the day before Christmas, if you fail to open up a few extra registers with experienced employees, your checkout service may be quickly overrun to the point where people will decide not to wait in line.You will lose business and therefore we would say that you had no business continuity.

■ Alarm If any of your operational security measures or loss controls fail or are circumvented, will you be informed? During a routine check of your web server log files, you notice a lot of traffic going to a particular internet-based client. It appears malware has somehow infiltrated this web server and has been able to open up a connection to another com­puter through your firewall. This routine log check has been a successful alarm.

Connecting the Dots

The OSSTMM methodology has a solid base which may seem quite involved but that's actually easy in practice. As you can see in Figure A.3, it's just like a flowchart. But it's not. The flow is more integrated and while the beginning and the end are clear, the path is defined by the tester, and the time is allotted to the test.This is because no methodology can accurately assume the business justifica­tion for channels that have been provided. More directly, the OSSTMM doesn't assume best practice. Best practice, or common criteria, or whatever it's being called these days, is only best for some. Business dictates how services should be offered and those services dictate the requirements for operational security, not the other way around. Therefore, a methodology that is different for each test and each tester is exactly what is required for thorough testing.



Figure A.3 Security Testing Methodology 3.0 from the OSSTMM



The OSSTMM begins with a posture review and ends with log verification. This is a full-circle concept where the first step is to be aware of the legalities and operational requirements of those that operate and interact with the scope, which then ends with reviewing the records our tests have left behind. In simpler terms: you know what you need to do, you do it, and then you check what you have done.The "doing" part itself, however, gets fairly involved, as can be seen in Table A.2.

Table A.2 The Security Presence Channel Descriptions

OSSTMM Modules Description

Role of the Search Engine



Posture Review

A thorough review of the Determining applicable laws legalities and operation and legal jurisdictions, loca-requirements of operations tions of primary clientele, interacting with the scope. business requirements by

industry regulation, financial obligations, or ethical requirements.



Logistics

Intrusion Detection Verification

Visibility Audit Controls Verification

Access Verification

Reviewing distance, speed, and fallibility (yours and theirs) to recognize failure possibilities in the results.

Verifying the practice and breadth of intrusion detection.

Measuring the use and effectiveness of loss controls.



Measuring the breadth and depth of interactive access points within the scope.

Researching the location, environment, and culture.

Researching discovered security mechanisms for the maximum depth and cov­erage possible.

Investigating references to the scope or parts of the security presence.



Continued

Table A.2 The Security Presence Channel Descriptions

OSSTMM Modules Description

Role of the Search Engine

Process Verification

Configuration Verification

Property Validation

Segregation Review

Exposure Verification

Determining the existence of security processes and measuring these processes for effectiveness.

Determining the proper configuration of access controls and applications.

Measuring the breadth and depth of the use of illegal and unlicensed intellectual property or applications within the scope.

A gap analysis between privacy requirements by law, by right, and by actual practice.

Uncovering information that provides for, or leads to, authenticated access or that allows for access to multiple locations with the same authentication.

Researching discovered security mechanisms for related security processes, management requirements, or service-level agreements.

Researching discovered security mechanisms for the depth and coverage possible through suggested configu­ration.

Investigating to find the real or true information and information owners.

Investigating regional privacy laws and requirements.

Discovering exposed information leaked publicly.

Competitive Uncovering intelligence

Intelligence Scouting that could harm or

adversely affect the scope through external, competitive means.

Determining and measuring the effective use of quarantine for all access to the scope.

Investigating known competitors, similarities to current practices, and leads for exposed information leaked publicly.

Investigating quarantine methods as well as potential hazards that can be tested in the existing quarantine.



Continued

Table A.2 The Security Presence Channel Descriptions

OSSTMM Modules Description

Role of the Search Engine

Mapping and measuring the impact of misuse of privileges or unauthorized privilege escalation.

Determining and measuring the resistance of the scope to excessive or adverse changes.

Alert and Log Review A gap analysis between

activities performed with the test and the true depth of those activities as recorded, or from third-party perceptions.

Translating scope information into ideas for creating false identification, false authentication, and privilege escalation.

Investigating known environmental instabilities and common threats of Denial of Service to and from the scope.

Investigating outside perfor­mance and increasing the comparison scope of the gap analysis to other industries or countries.



A proper security test may be a methodical flow, but it's far from being a sin­gular flow from start to finish. As testing continues, the tester will often have new information requiring verification in other test modules and this will continue to occur until the test expires. As stated in the OSSTMM's Rules of Thumb, the permission to perform verification tests should never be scheduled to end prior to the delivery of the report. And it is the delivery of the report, a written, verifi­able document, which marks the difference between professional security testing and just playing around.

Summary

Professional security testing requires a methodology. The methodology most often used is the Open Source Security Testing Methodology Manual from ISECOM, which applies the volunteer efforts of thousands of people interna­tionally. This manual provides results in three aspects: as operational security, a metric which determines the amount of security required for operations; loss con­trols, a metric for determining the amount of loss prevention in security mecha­nisms; and actual security, the current state of operational security and loss control effectiveness. These three aspects are the result of practicing the methodology itself, a combination of five possible channels as gateways to intellectual or phys­ical property within the security presence, categorized as the telecommunications, wire­less communications, data networks, personnel, and physical channels.



0 ISECOM Discussion is the primary list available for OSSTMM help, feedback, and volunteering efforts.

0 ISECOM News is a low-traffic list for providing project release and update information as well as information about ISECOM events.



Frequently Asked Questions



The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the "Ask the Author" form. You will also gain access to thousands of other FAQs at ITFAQnet.com.

Q: Who uses the OSSTMM?

A: Since the OSSTMM is freely available to all for download, ISECOM has no way to know all those who do apply it or require tests based on it. By the time of this printing, however, it will have been downloaded approximately two million times.



Q: How does the OSSTMM compare with other security methodologies such as BS 7799 or OCTAVE?

A: OSSTMM is a low-level, bottom-up verification of the policy information audited by higher-level methodologies like those mentioned. OSSTMM is completely compatible with them and will enhance any risk assessment or management methodology by providing a basis of fact on security effective­ness.



testing

Q: Are there other penetration testing methodologies besides the OSSTMM?

A: First, OSSTMM is not a penetration testing methodology. Pen testing, as it's known, is a subset of a security test that often just pits an "ethical hacker" or "pen tester" against a challenge within a par^^lL^m^ frame. Relatively little is actually achieved other than attempts to reach the stated goal, and it is most often a test of the tester than one of the scope. OSSTMM goes far beyond data networks alone to provide a thorough security test that includes valid metrics and a complete report of the effectiveness of all security mecha­nisms in operation. This also leads to the answer that there is nothing else out there like the OSSTMM. At least not yet.

Q: Is it required to test all channels to do an OSSTMM certified security test? A: No, only one channel needs to be thoroughly tested.

Q: I have ideas to improve the OSSTMM. How can I help?

A: The best place to share ideas is the ISECOM Discuss list. Most OSSTMM developers are on that list.You can also write the author directly.



Q: The OSSTMM is fairly involved. Where else can I find help with it?

A: Check the ISECOM Web site for seminars, help guides, core team members from your region, and the official OSSTMM certification classes.

No comments:

Post a Comment