Neohaxor.org

This year at Black Hat USA 2010 and Defcon 18 Marcin Wielgoszewski and I did a talk called Constricting the Web: Offensive Python for Web Hackers (video). The basic premise of our talk is that web architectures and technology are getting far more complicated and it is not sufficient just to run a vulnerability scanner on an application and call it done. Individuals tasked with testing these architectures are going to need to write their own tools and tests at some point. If you aren’t taking security beyond your vulnerability scanner then you aren’t performing the proper due care and due diligence required to protect your assets.

More information on tools and projects to come. I just don’t feel too much like writing today

Write Your Own

It’s inevitable at some point you are going to have to write your own tools and tests. Modern web architectures no longer consist of a page with a simple backend web server. Complex items such as RIA technologies, APIs, aggregators, and custom protocols are now thrown in to the mix. Vendors continue to lag behind the technology curve which puts commercial tools at a disadvantage. All of these items need to be tested in order for organizations to have any type of success in their testing efforts.

This is where you take the code in to your own hands. It really isn’t as difficult as it may sound. I know quite a few people that shy away at the thought of writing their own code. I am not quite sure why there is so much apprehension about writing your own code. Maybe people are having C flashbacks from college or something.

Modern languages have quite a bit of the work already done for you. Python, which is my weapon of choice, has a vast amount of modules that allow interfacing with many different protocols. In the end all you need to do send and record your tests. Python is also a rapid development language that is easy to read and write, making it great for security people who don’t want to spend all day writing code.

Black Hat Wrap-up

We are participating in the Black Hat Wrap-up webcast. We are going to summarize our talk and highlight a few items. This is happening Thursday, August 19th at 4pm Eastern. Information on the webcast can be found here: https://www.blackhat.com/html/webcast/webcast-2010_BHUSAwrapup.html

Tools Released

We also released a couple of tools. Most notable is Marcin’s Burp API. It allows you to interface with Burp logs and turn them in to objects. This would allow you to do anything from replaying tests, creating your own macros, and even creating your own vulnerability scanner. Burp API information can be found here: http://mwielgoszewski.github.com/burpee/

I also released a stand alone encoder that I wrote a while back. The main reason was I just like having a stand alone encoder when I am doing assessments. It allows you to encode and decode values as well as wrap values with different characters. You can get more information on DharmaEncoder here: http://code.google.com/p/dharmaencoder/

Finally, I created a Python web fuzzing module called pywebfuzz. The pywebfuzz module allows you to have values available for testing from the fuzzdb project as well as some convenience functions for range generation and making requests. The module is in it’s early phases but still usable. I have a bunch of miscellaneous things I need to do to it before it is where I would like it to be. More information on pywebfuzz can be found here: http://code.google.com/p/pywebfuzz/

If you run in to bugs please let us know so we can get them fixed. If there are features you would like to be added please let us know that as well.

Conference Materials

The conference materials are posted on the Hexagon Security site. You can download them here: http://hexsec.com/docs

Ok, first order of business, I love Dropbox. If you are unfamiliar with Dropbox it is a popular cloud based syncing / storage / sharing application for your files. It allows you to store files, roll back changes, etc. You can get more familiar with them by visiting their site https://www.getdropbox.com

Now that I am done singing the praises of Dropbox, it’s time to get to the nitty gritty. This issue isn’t necessarily devastating for Dropbox, but could lead to some larger issues with other cloud based providers. The reason I am writing about this issue is because I think it can aid other individuals in the design of their applications. Let’s face it, cloud based applications and storage aren’t going anywhere.

What You Should Notice

One of the first things you should notice after installing Dropbox is that it sets up some files and folder structure for you.

A few of the folders are Documents, Photos, and Public. A couple of files that show up are This is your Dropbox.txt and if you have installed the iPhone app you get the iPhone intro.pdf. Your Public folder is where you can put files that you want to share with via a public URL.

So by default you get a Public folder with a public file that is shared called “Top Secret.txt”. If you go to the Dropbox menu you can obtain a link for the public file that has the following structure:

http://dl.dropbox.com/u/{acct number}/Top%20Secret.txt

So now you have a known resource  with a known location. By simply requesting this resource and changing the account number you can enumerate through valid accounts. In doing this it will become apparent relatively quickly that account numbers are sequential. You would also notice that most people do not delete any of pre-installed default files even though they are unnecessary. These files are Dropbox’s way of communicating with you about what the folder should be for or about something the application does.

It is fairly simple to enumerate through account numbers and come up with a list of valid users, you could do this in just a couple of lines of Python code:

#!/usr/bin/env python
 
import httplib
 
f = open("dropbox_accts.txt", "w")
 
for num in range(1440000, 1450000):
    request_string = "/u/{0}/Top%20Secret.txt".format(num)
    conn = httplib.HTTPConnection("dl.dropbox.com")
    conn.request("GET", request_string)
    req = conn.getresponse()
    if req.status == 200:
        print(req.status)
        f.write("{0}\n".format(num))

What this does is enumerate through account numbers from 1440000 to 1450000, and if there is a return on Top Secret.txt, it records the number in to a file called dropbox_accts.txt.

Why This Is A Problem

This is a problem for multiple reasons. First of all, it allows an attacker to determine valid accounts on the system. This gives an attacker a starting point for an attack on an account. Another thing to note is that it shows accounts are created sequentially which could lead to other issues.

Working on account enumeration it would be possible for an attacker or someone tracking Dropbox to determine how many new users they have per a certain period of time just by starting where they left off with their previous enumeration activities.

The issue might allow an attacker to try to obtain some information about a particular user through sifting through their public files, if they were guessed. Yes, an attacker would have to guess the name of a valid file but we as humans tend to name files descriptively, so it may be easier than it seems. There is no randomness attached to the filename /URI that would deter this type of activity. After sifting through this data it may be possible to determine the name of the individual who owns the account. Another thing you might find from this activity is an email address associated with the login of the account. If they were to obtain the email they would have the login (email), account number, and the person’s real name. It would not completely out of the question to find something like resume.doc in a user’s Public folder. This is a lot more than an attacker should have.

Now this shouldn’t be a huge deal because it is a “public” folder, it should be assumed that everything in there could be accessed by anyone, but people don’t always make the best choices when it comes to sharing. Many people who use Dropbox use this folder to share things with their friends, not the entire world.

Probably most important, is that they are using known resources and locations. This can be a particularly bad issue for cloud based applications due to their public nature. Every Dropbox account has several folders set up by default along with several files added. These rarely get changed and just get utilized by users. Giving an attacker known resources and locations goes a long way to a successful attack. It allows an attacker to gauge success or failure of a given attack and gives them ready-made resources on which to focus their attacks.

Dropbox uses these files in their private directory structure as well, which opens the doors for some interesting possibilities. I have not really dug in to their API or too much in to their web interface to really say where this might be an issue, but the groundwork can be done in relatively small period of time.

Without having any kind of knowledge how the back end of Dropbox works, it’s hard to tell whether any of the information (ie Account Number) that can be be enumerated can be used to attack user files at rest. It may be hugely important or totally innocuous. I am assuming they have probably thought of this, but you never know.

What’s The Takeaway

People designing cloud based applications and storage should be aware that creating items with known locations could increase their attack surface by giving attackers something to work with. This should be kept to a minimum. Users should be defining the structure of their storage and setting up names for their resources. If you need to communicate with users, it should be done in a message format vs leaving a standard named file in a known location.

Public resources, even though they are public should have some form of randomness added to their resource locations. This way, it is not extremely easy for an attacker to enumerate resources and gain information about the application and its users. It would be a better idea to take the approach that Flickr does with it’s randomized URLs for photos. That way it is not easy to map a resource to a given user or account number.

When numbers associated with accounts are exposed, they should take on some form of randomness or there should at least not be any exposed method that would allow someone to enumerate through them easily.

Threat modeling should be done on the application during the design phase allowing for the identification of issues before they get worked in to production. Always think about how the application could be abused. You would think this would be second nature by now, but so many organizations are not doing this.

If you are Dropbox user you should delete the default files that are created by Dropbox, especially the Top Secret.txt that is in your Public folder.

In Closing

In closing not extremely devastating on the surface for Dropbox, but definitely food for thought for anyone working on the design of cloud based applications. Issues like this are definitely not isolated to Dropbox. I wrote a tool about a year and a half ago (that I had forgotten about by the way) for pulling valid users and data out of Apple’s MobileMe service. An issue that still exists to this day. Cloud providers need to be thinking about this stuff in the design phase because it is hard to make changes after deployment.

MonkeyFist is a dynamic request attack tool. It allows you to do some interesting things with various forms of cross-site requests and play them back to the user’s browser. These requests may contain session information bypassing Cross-Site Request Forgery protection mechanisms. It’s really a lot more simple than it seems.

MonkeyFist is basically a small web server that performs some attacks on the data it receives based on information you provide in the payloads.xml file. To do a deeper dive in to the issues that MonkeyFist exploits you can refer to the white paper we wrote prior to Black Hat on Dynamic CSRF located on the docs page of Hexsec http://hexsec.com/docs

The best way to get familiar with MonkeyFist is just to dive right in. If you haven’t done so, you can go here to download it from the Hexsec Labs page http://hexsec.com/labs

MonkeyFist requires you be intimately familiar with the request you want to forge. This should be painfully obvious because you need to tell the tool how to construct the request in order for it to be successful.

The Files

There isn’t much to MonkeyFist, all of the files are pretty small. There are a few items in the zip file, but you really only need to worry about MonkeyFist.py and payloads.xml. All of the configuration for payloads in MonkeyFist is done through payloads.xml. We will get in to syntax in another post. In case you didn’t notice the .py extension, MonkeyFist is written in Python. So if your operating system doesn’t have Python installed (Probably just Windows systems) you are going to need it. I suggest version 2.5 or greater. The version that comes with most Linux distributions and OSX is fine. As a final note about the files, ensure that you run MonkeyFist from the same directory as the other files that come with it. Otherwise, it won’t know where they are located

Dependencies

In the beginning there were no further dependencies but I a saw it was necessary to potentially need to do some more complex parsing for the fixation payload. For that reason I decided to add lxml. I could have gotten away with a more simple parser, but was trying to think ahead a bit. To use the Fixation payload you are going to need to install a 2.x version of lxml. This would be different depending on your operating system. If you are using Ubuntu / Debian don’t just to to apt install lxml, it will give you an old version. Python setuptools helps a lot, it’s just a good idea to use that anyway.

For OSX Leopard (Make sure you have the development tools installed) I just ran:

sudo easy_install lxml

For Ubuntu you have to take a few other steps because you need a few dependencies and the development headers for Python.

If you don’t have setuptools installed:

sudo apt-get install python-setuptools

Then you need to apt-get install the following if you do not have them installed:
libxml2-dev
libxslt1-dev
python2.5-dev

After that you can go ahead and:

sudo easy_install lxml

If you have build problems you probably don’t have the build tools installed:

sudo apt-get install build-essential

Then run easy_install again.

If you decide not to run lxml or do not have the ability to install it, the tool will still run you just won’t be able to use the Fixation handler without a nice failure and error message

Payload Types

There are several types of payloads you can construct with MonkeyFist. Each of these would depend on what the goal of the attack would be or the type of content on a site you would have control over. The basic payload types are dynamic redirect, POST construct, dynamic page, and fixation.

Dynamic Redirect

The dynamic redirect payload simply parses any cross-domain information looking for session data to dynamically construct in to a GET based payload to send back to the user’s browser. Basically, the user would request something and the tool would respond with a 302 redirect to a location. The location value would be the constructed payload. The user’s browser would just request content like normal and follow the redirect and execute the payload.

This payload type is best used in instances where you have the ability to add images tags or other HTML to a site. This way it could be relatively hidden from a user’s browser.

Dynamic Page

This payload constructs a page that performs several functions depending on what type of attack you are performing. You can either have the page perform a GET or a POST for an attack. Both the GET and POST types will be submitted by the user’s browser. So what does the page do? The attack that you construct gets embedded in the page and after the attack happens the user is immediately redirected to a location of your choice. So you could perform an attack and immediately send someone to the Benny Lava video This could be combined with an URL shortener for further obfuscation.

This payload is best used in instances where you have the ability to embed hyperlinks to pages. Another thing to note about the dynamic page payload is that it makes POST based CSRF a whole lot easier to pull off. If you thought submitted data as a POST was a protection mechanism for CSRF you might want to rethink you point of view

POST Construct

This payload is a bit different because the POST request is made by the tool and not the user’s browser. This needs to be kept in mind when using it. You will not have the advantage of the browser being helpful and submitting header information. If the cross-domain leakage is enough that you can perform an entire POST request without the user’s browser then this payload can be used. Otherwise, it will be pretty useless to you

Fixation

The fixation payload allows you to make a request for data that you fixate on to the attack you send to the user. This is still experimental and only works in some narrow situations. This will be expanded later. This works as a modified page payload that performs and extra request and parses the response and gains the necessary information to perform the attack. This would be commonly used to make a request for tokens that you can fixate on to a request forged by the user’s browser.

Default Payload

The default payload gets matched when there is no cross-domain information for the tool to match with your entries in the payloads.xml file. It’s best to not perform an attack with this The best thing to do is to make this a link to some real content like an image. This can make the tool a bit more stealthy.

You need to specify a default payload. Not doing so would be like crossing the streams. Well maybe not that bad, but it wouldn’t be good.

MonkeyFist Running Options

There are only a couple of running options with MF and well, all of them do not work as of yet. So, the main one you need to be familiar with is -s. This is the standard attack mode. The -p option specifies the port you would like MF to run on. You won’t need privileged access unless you are trying to run on a low order port. The following would run MonkeyFist on port 8080 using standard attack mode:

./MonkeyFist -p 8080 -s

You can get the about information by running -a, just in case you were curious about what version you are running.

./MonkeyFist -a

Of course, if you need some reference there is always the ole’ help with -h

./MonkeyFist -h

There are a couple of other options that are planned for the future. A testing mode and a random mode will be added as well, but currently, they are not implemented.

Payloads

The payloads.xml file is where you define your attacks. This is where all of your work will be done. The exact options that are specified in this file are still being worked out. This is because as content goes, there needs to be flexibility when identifying these issues. There is a basic set of options that allow you to pull of some attacks even as MonkeyFist sits at version 0.4. Expect some changes in these options. The payloads.xml file will be covered in more detail in a future post.

The Others

You will notice a few other files in the MonkeyFist zip file. You might not want to delete them or you may have some unintended consequences. The page2.html file is blank, but it won’t be if you pull off any Page attacks. Contents are put in to this file dynamically and change per attack. Markup.py is something I didn’t write, it just allowed me to quickly generate some HTML. This was before I made the decision to use lxml. For now I am going to leave it in there, even though it is not the best option. FistLib.py is the most important. This is the workhorse that takes care of all the work.

In Closing

I think that’s it for a small intro on MonkeyFist. In future posts I will explain more about the payloads and how they are constructed. If you notice any problems while running MF please let me know. You can send an email to monkeyfist {at} hexsec {dot} com. This is still a work in progress so please don’t beat me up too bad. I do welcome your feedback though. Thanks.

Bypassing CSRF Protections With Dynamic CSRF

At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk called Weaponizing the Web: More Attacks on User Generated Content. During the talk we discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic CSRF methods can be used to create new attack vectors and compromise CSRF protection mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post about it and link our Dynamic CSRF White Paper.

Static CSRF Attacks

The current way people are exploiting CSRF issues is pretty static. A link may be crafted and people are tricked in to clicking on it or viewing a page with this link embedded. They may even do something such as create an auto-submitting POST that the user executes when visiting certain content. The moral is that someone crafts this attack for a specific location and chooses a vector for delivering it to users. On it’s own, this static CSRF attack method can be pretty devastating or perhaps totally innocuous. That’s just the nature of CSRF. There aren’t too many vulnerabilities that fall in to this category, which may be why it can sometimes be hard to understand.

Let’s just think about some things that would make CSRF even more dangerous. What if we had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user was on the site that we wanted to attack? What if we could use a central point to dynamically attack multiple sites? What if we could create a custom payload on the fly to include tokens and session data? What if we could request data in another process and fixate it on to a request that the user executes? CSRF would become much more dangerous. Well, it just did….

Dynamic CSRF Attacks

With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where requests are originating from. Sensitive information sent in a cross-domain fashion can be packaged in to a customized payload and sent to a location. Disjoined or bolted on components can be queried and fixated on to a user’s request. This opens up new opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks for multiple sites and applications with the ability to remove and repackage any leaked session information.

Using dynamic methods may allow for the bypass of CSRF protections. Whether these protections are leaked in the referer or if they can be requested by other means and fixated on to the request, bypassing may be possible. This makes requests that were previously not vulnerable to CSRF vulnerable again.

When not limited by static requests a few new attack vectors open up. I just wanted to highlight a couple here.

Getting Dynamic

In the next couple of sections I am going to point out some dynamic methods for bypassing CSRF protection mechanisms.

HTTP Redirect

A simple redirect attack can be made more devastating with the addition of session related data added to the request. So a user hits a piece of HTML on a web page that sends a GET request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session data can be taken from the referer and repackaged in to a payload that is sent to the users browser as a location for a 302 redirect.

A scenario for this type of attack might be embedding a hidden image tag that links to a location offsite. This image tag may leak session data through referer allowing a tool to repackage that session data and get the user’s browser to execute it as a payload. This could be used to bypass CSRF protections by using the CSRF tokens from the referer.

HTML-based Redirect

For this scenario a hyperlink could point to a page that is created dynamically per-each request. This page contains a hidden GET or POST that could contain session data taken from referer as mentioned previously in the HTTP Redirect. The page would then refresh to a legitimate destination. To a user there would only appear to be a short pause prior to their landing on the legitimate destination, but in the background an attack has happened.

This attack could be made more interesting with URL shortening services. People have become accustomed to URL shorteners due to their use of Twitter and other social networks. Using a URL shortener would mask the location of the dynamic page and may not raise further suspicion.

A scenario for this would be posting a link that is shortened with a URL shortener on a web site that supposedly links to a video on YouTube. When the user clicks the link a hidden action (GET or POST) is executed. After the hidden action takes place, the browser does a refresh to the expected destination (the YouTube video). The victim may get little or no indication that the hidden attack has happened.

Fixation Based Attacks

Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF token and a valid session identifier, but those two values aren’t associated together from a session perspective. Say you are posting on a message board. This message board issues you a Session ID in a cookie and also issues you a token for use when posting. If these two values aren’t linked from a session perspective, it would allow for any valid token to be added to the request. Since the Session ID is in the cookie value, if a forged request had a valid token appended this would bypass CSRF protections.

What makes this fixation attack an interesting scenario is it requires no leaking of any session data in a cross domain fashion. As long as you have some visibility to the token, it can be requested and fixated to the request.

Other Scenarios

There are other scenarios as well. It really depends on how much session data gets leaked in a cross-domain fashion. For example, if the full session ID is leaked, there could be some real problems. It could allow for a tool to construct any GET or any POST to the target application.

MonkeyFist

MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on a system listening for all incoming input. When it receives a request it looks in the referer to determine where the request is coming from. It then uses this information to parse a payloads file and look for the specific attack to construct for that domain. You can have multiple entries in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST) and an Experimental Fixation handler are all included in the application. You can learn more about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be, but it works. More streamlining and modifications will come soon. I am still recovering from Black Hat and Defcon

I have some posts on MonkeyFist that are coming soon as well.

More Info

That’s it for a quick intro to Dynamic CSRF. If you would like more information you can read our white paper which is available here.

I just wanted to let everyone know that Shawn Moyer and I will be speaking at both Black Hat and DEFCON on attacking social networks. The presentation is called: Satan is on my Friends List: Attacking Social Networks. The presentation covers both social and technical attacks on social networks. Come by and check it out. The schedules are available here:

Black Hat Schedule

DEFCON Schedule

I have had plenty of interesting conversations with people on this topic. Everyone seems to have a different opinion. There has been quite a bit of discussion around web application firewalls (WAFs) with the PCI DSS 6.6 requirement looming. I am glad that the PCI Standards Counsel has given some clarification around 6.6 as to their intent and compliance. The information can be found here:

Here

I think they rather well explained their position and they have great cause for concern in this area. This particular section of the PCI DSS has now sparked quite a few debates. PCI 6.6 basically states that you ether have to have code review or a web application firewall (WAF). I am sure that WAF vendors are ecstatic. I feel the finding will have people opting for the WAF and figuring they are secure. This is not the case and is a false sense of security. Always remember, when it comes to the protection of your assets it is still your responsibility.

Validating the Code

The clarification document specifies a few different methods for validating the code. Each of the different methods would yield different results based on the individuals doing the assessment. This is easy to find in just about any standard or piece of compliance. I really believe the intent is to find the big vulns and the low hanging fruit. There are still so many applications vulnerable to SQL injection and XSS it isn’t funny. Would the methods described by the PCI clarification find these vulnerabilities? For the most part I think yes. Each method described can have wildly different results but each method should (for the most part) at least alert someone to the existence of these basic vulnerabilities. At the very least it raises awareness.

Now what about this whole other world that lies outside your door? This world that deals in actually trying to secure your applications? Well that is a door that organizations are going to have to choose to walk through on their own. We all know there are plenty of organizations that won’t choose this door.

There is always a difference between complying with standards / compliance and doing what you are supposed to do. Should you just try and comply and take the easiest road possible? Of course not. There are always going to be organizations that do just try and comply. By the time issues make it in a piece of regulatory compliance it is way too late and often too little. Standards and regulatory compliance have to be broad so they can deal with many organizations and try to accomplish the intent for each of the requirements.

One other thing I noticed about the clarification document was the use of the word “qualified”. That is an extremely generic term that is left up to quite a bit of interpretation. Having an individual internal to the organization have the final say on the application assessment is not a good idea in my opinion. I am a big believer in 3rd party validation. A 3rd party, experienced in analyzing web applications, should conduct the assessment (when compliance is involved). This experienced 3rd party should also use a variety of methods to verify that the application exhibits an appropriate level of security.

WAFs?

What about using a WAF instead of analyzing the application? You should never use a device to cover up a vulnerability and call it quits.

“Well we can’t patch our boxes so we might as well just use a firewall”

The previous statement doesn’t make sense. There are two many other variables in play to make this a viable solution for protecting your assets. What is someone misconfigures the device? What if the device fails open? What if the firewall has a vulnerability? The list goes on and on. With web application firewalls it can be far worse. With web applications, most often sensitive data is just a few steps away from any attacker already. The only true way to secure web applications is through proper design, coding, configuration, and maintenance. You should never, ever just cover up a vulnerability that you know about. Plus can you imagine having to explain to people, “Yeah we got owned, but I thought we had the vulnerability covered up”.

Web application firewalls, like network firewalls, are a layered security control. These layered controls are what you use in addition to other controls to protect your assets. Layered controls should never be used as primary controls, unfortunately this is often the case.

Basically the reasons to not just use a WAF are as follows:

1. Misconfigurations could leave you vulnerable.
2. A fail open situation could leave you vulnerable.
3. Depending on configuration wouldn’t protect you from internal personnel and business partner networks.
4. Vulnerabilities run deeper than just SQL Injection, XSS, and other common web flaws. Flaws in business logic and session data are pretty devastating too.
5. Unforeseen vulnerabilities in the WAF product itself.

I just listed a few quick points and there are more. On another note, I have never ran in to a situation where an application had something devastating like a SQL Injection vulnerability and the rest of the application was just fine. There are usually other flaws in logic and authorization as well. These are all items to consider when designing your protection strategy.

What should you do?

Ideally you should implement both the analysis of the application and the WAF. This will afford you the best protection. You will have the knowledge of knowing your application is solid and get the advantages of protection and logging from a WAF. This is assuming you use the right vendors for both but I am not even going to touch on that in this post.

What if there is no access to source code to fix flaws?

If there are vulnerabilities identified and there is not access to source code for whatever reason you should implement the WAF while you work on the fix. If it is a COTS application then you should contact the vendor and have them work on a fix. If it is a custom built application a plan should be put in place to deploy new code that complies with proper coding procedures. Developing new code is definitely a pain, but will serve you much better in the long run and will help ensure that you don’t get owned

You Shouldn’t Stop Here

You shouldn’t just stop here. There are plenty of other variables that affect the security of your assets. The environment, configuration, code management, policies, patches, and many other factors affect the security of your assets as well. Protecting your assets requires a holistic approach with a layered defense. If organizations are serious about securing their assets they will use a holistic approach and not just try to satisfy requirements. I just hope that organizations choose to do the right thing. I won’t hold my breath though, this hasn’t been the road traveled in the past.

Anurag Agarwal had a posting in his blog about a new certification for Web Application Security Professionals. When I first saw the posting I was almost kind of excited. You can imagine my disappointment when I found out that the GIAC/SANS organization was going to be involved. To me it just seems like an excuse for SANS to try and charge an exorbitant amount of money for their certifications. Now, I am not knocking the instructors that teach at the SANS training. Most of them are very talented individuals with many years of experience. That isn’t the issue.

What I have a problem with is what about people who already have the core competencies for the certification? These individuals would get absolutely nothing from taking the SANS training. I am sure the training is going to be targeted toward more of the newcomers to this space. For this scenario GAIC offers the certification challenge. I am not sure if you have looked up their costs to challenge their certifications or not, but it is rather laughable. I almost feel out of my chair laughing when I saw the new pricing, 899.00 which is a tricky way of saying 900.00. Are you kidding me? There is nothing special about their tests or credentials. I know, I have one. There can not be that much overhead in the exam creation and maintenance. The CISSP doesn’t even cost that much, initially anyway. It just seems like another way for this organization to money grub. They are targeting people who work for organizations that pay for certifications for them and don’t necessarily question the amount of money spent. This basically shuns the little guy and the independents. To me, the GAIC certification challenge for Silver (that is purely automated no grading of papers) shouldn’t be more than 150 dollars. I think that is fair.

How should this be done?

I am not an expert in all things certification but I would think you would have to start with the WASC taking complete ownership of this. Community experts should be queried for what they believe are the most important aspects of the field. You may even want to take a proven methodology based on OWASP as a framework for this as well. After that the exam objectives are defined. There may also be an experience requirement as well. So maybe people have to prove working in the field for 2 years or something such as that. Based on the exam objectives and the comprehensive nature of the exam, you have a panel of experts draft the questions for the exam. The exam delivery method should be one that doesn’t restrict people based on geographic limitations. This delivery method could be web based, Prometric, etc.

Structuring the exam in this manner would allow other organizations to provide training as well and not just lock in one vendor. This spreads the wealth a bit through the technology community. Also it would allow for a reasonably priced challenge for any professionals who are already proficient in this area.