mostly useless crap from me

A key component in deciding a risk is WHO is going to be doing the attack. The above image is from the excellent OWASP Top 10 2010, and I will be referencing this diagram a great deal.

We’re talking about the attackers (threat agents) on the left today. So you’re busy doing a secure code review or a penetration test (how I loathe that term – so sophomoric) and found a weakness. You’ve written up a fantastic finding and need to rate it so that your client (whether internal or external, for money or for free) can do something about it. It’s vital that you don’t under or over cook the risk. Under cooking the risk looks really really bad when you get it wrong and the wrong business decision is made to go live with a bad problem. Overcooking the risk erodes trust, and often leads to the wrong fixes being made or none at all, which is worse. You can tell if you’re overcooking a risk if your clients are constantly arguing with you about risk ratings. Let’s get to a more realistic risk rating first time every time.

Risk Management 103 – Establishing the correct actor

I am more likely to be successful than a script kiddy who is more likely to be successful than my mum. Unfortunately, there’s just one of me, but there’s a million script kiddies out there. That doesn’t mean you should use them. Script kiddies are simply unlikely to find business logic flaws and access control flaws, such as direct object references. So you should reflect this in your thinking about risk – even though it might be simpler to go with what everyone already knows:

• Skill level – what sort of skill does the threat agent bring to the table? 1 = My mum. 5 = script kiddy (generous), 9 = webappsec master
• Discovery – how likely is it that this group of attackers will discover this issue?
• Ease of exploitation – how likely will this group of attackers exploit this issue?
• Size of attacker pool – 0 – system admins or similar, 9 – The Entire Internet (==script kiddies)

So you need to do the calculation for the weakness you found for these various groups to determine the maximum likelihood. This often leads into impact. Let’s go with an indirect object reference, such as the AT&T attack

Likelihood – AJV

• Skill level – 9 web app sec master
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 7 easy
• Ease of exploit – 5 easy
• Awareness – 9 public knowledge
• IDS – Let’s go with Logged without review (8)

This brings us a total of 54 out of 72. I put this as a “HIGH” likelihood in my risk charts.

Likelihood – Script kiddy

• Skill level – 3 some technical skills (script kiddy)
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 1 Practically impossible
• Ease of exploit – 1 theoretical
• Awareness – 1 Unknown
• IDS – Let’s go with Logged without review (8)

This brings us to 34. So we shouldn’t consider script kiddies when there might be a motivated web app sec master on the loose. But is that entirely realistic? Honestly, no.

Who is really going to attack this app?

Think about WHO is likely to attack the system:

• Foreign governments – check.
• Web app sec masters – Our careers are worth more than the kudos.
• Bored researchers trying to make a name for themselves – check even though quite dumb (see previous bullet)
• Script kiddies – check but fail. Realistically, unless someone else wrote the script, they wouldn’t be able to do this attack.
• Trojans – check but fail for the same reason as script kiddies.
• My mum doesn’t know what a direct object reference is. Not going to happen.
• Terrorists – check, but seriously, remember dying by winning lotto, buying a private plane with the lotto winnings, having the plane struck by lightning on its four leave clover encrusted hull eight times, parachuting out and then for the main and the secondary to both fail is more likely than a terrorist attack. Don’t use this unless you’re after Department of Homeland Security money as everyone else will just laugh at you. Especially if you use it more than once.

So let’s go with #1 as this is an attack that they would be interested in. They have resources and skilled web app sec masters, so this attack likelihood is a HIGH. So let’s work out the impact for this scenario:

Sample Impact Calculation

There’s a lot of subjectivity here. You can close that down significantly by talking it over with your client. This doesn’t mean you should go with LOW every time you have the conversation, but instead set out objective parameters that suits their business and this application. Yes, this takes a fair amount of work. You can either do it before you deliver the report, or you can do it after you deliver the report. If you choose the latter path too often, your reputation as a trusted advisor can be found in the client’s trash bin along with your reports and the client relationship.

Let’s do the calculations based upon the sketchy information I have from third hand, unreliable sources and vastly more reliable Tweets. i.e. I’m almost certainly making this up, but hopefully, you’ll get the picture.

• Loss of confidentiality. Check big time. All data disclosed (9)
• Loss of integrity. In this case, no data was harmed in the making of this exploit 0
• Loss of availability. If every government tried it at once, I’m sure there’d be a DoS but let’s be generous and say minimal primary services interrupted (5) as the system would have to be taken offline or disabled after it was discovered
• Loss of accountability. It’s already anonymous, so 9
• Financial damage. AT&T is big. Really really big. In the grand scheme of things, this probably didn’t hurt them that much. That said, it has to be in the millions. So let’s go with Minor effect on annual profit (3)
• Reputation damage. AT&T’s reputation is somewhat already tarnished, so let’s go with loss of major accounts (4) as I’m sure RIM will pick up all of those .mil and .gov accounts very soon now.
• Non-compliance. PII is about names and addresses, but AFAIK, e-mail addresses are not protected at the moment. Happy to hear otherwise – leave comments. Let’s go with “clear violation” 5
• Privacy violation. 114,000 is the minimum number, so let’s go with 7 and it could tip towards 9

This gives us 42 / 72, which is a MEDIUM impact (just shy of “HIGH at 46), giving an overall risk of HIGH. That is about right, and thus should have been caught by a secure code review and fixed before go live.

Next … Risk Management 104 – Learning to judge impacts

There’s a lot of consultants (and clients) who know little to nothing about proper risk management. This is not their fault – it was never taught at computer science or most similar courses. If you get good at it, you’re unlikely to be a developer or a security consultant. That’s a shame, because risk management has a lot to offer both consultancies and their clients if done properly.

The problem is that most consultants think technical risk, and will happily assign “Extreme” risks to things like server header info disclosures. Many clients actively campaign to reduce risk ratings for whatever reason, some for valid reasons, others not. And they will win if the risk ratings are wishful thinking or outright wrong. This could cost the organization billions of dollars if a HIGH risk becomes a LOW risk and is accepted, when really it’s a sort of a MEDIUM to HIGH risk depending on the situation.

We as consultants have a responsibility to THINK about the findings we put into reports. Don’t be a chicken little, but also don’t be bullied into reducing bad risks as you’ll be chosen for your outcomes rather than your honesty and integrity. Be open and honest about how you came to that risk decision, talk over the factors, and help the client understand and agree to the choices you’ve made. So don’t just stick “HIGH” in there, you need the entire enchilada. Lastly, be reasonable when you’ve made a mistake and ensure there’s as few as possible as that’s a huge reputation risk.

Clients have a responsibility to talk over the risk ratings so they fully understand the risk. All parties should agree that they document the original risk, the discussion about the risk, and any revisions to the rating and / or vulnerability. Maybe there’s a control that’s being missed, or may be there’s a misunderstanding of how easy it is to perform. Otherwise, there’s no accountability. In the end, consultants should never change a risk without documenting that change.

How to improve the situation

I like the OWASP Risk Rating methodology. The primary reason is that two different consultants can come up with the same result independently, removing a lot of the subjectivity and argument from the equation. I like to include the entire calculation as this allows clients to repeat my work and thus understand why it turned out the way it did.

There are issues with the OWASP Risk Rating methodology:

• It’s far too easy to generate “Extreme” risks. Extreme risks are really, really rare. They are company ending, life ending, project ending, shareholder value strippers, reputation destroyers. Think BP and the Gulf Coast. SQL injection at TJ Maxx is an extreme risk (despite them still being in business, it did cost a lot).
• It’s difficult to game the numbers to create “Low” risks when you know that it really should be a “Low”. I basically take nine off the top, as I’ve never gotten a value less than nine. This helps a bit, but even then.
• It’s hard to do it manually. I use Excel spreadsheets, but you may want to automate it more.
• You must talk to your customers first. Otherwise, you need to take out the business elements (financial, legal, compliance, privacy) as you will not be able to lock these in.
• Impact values are not the same for the entire review. They change as per the asset value/classification, and you will most likely have more than one asset value / classification in your review. There’s a difference between contexts, help files, PII, and credit cards. Document which one applied.

That said, the OWASP risk rating methodology is way better than pretty much everything else out there for web apps. CVSS is not suitable as it’s for ISVs who produce software. That doesn’t describe most enterprise, hobby, open source projects, and so on. If you need to do AS4360 risks, CVSS is not going to cut the mustard.

Risk Management 102.

We spend a lot of time arguing with some clients because we haven’t thought through our risk carefully enough, or worse, just used the one from the last report. No two clients and no two apps are ever the same. Therefore, the risk ratings for each of your reports MUST be different. Spend the time to do it right the first time, or you’ll spend a lot more time later when your client argues with you. And they may have a point.

• Try not. Do… or do not. There is no try. The likelihood rating is solely about the likelihood of the MOST SKILLED threat agent SUCCEEDING at the attack / weakness / vuln you’ve described.
• The impact rating is solely about the WORST impact of the attack / weakness / vuln using the threat agent you’ve described.

For example, you have a direct object reference in the URL and no other controls – my Mum could do this attack. The IMPACT is off the charts, and the likelihood too. Just because a n00b consultant with an automated tool is unlikely to do more than annoy the web server, doesn’t mean that’s the threat agent you should document.

If you came so, so close to exploitation and you just know that it could be bad, but you failed miserably after several hours, exploitability has to be set to 0. Seriously. The impact has to be low too, as there’s no impact that you’ve proven. To document anything else is wrong. I’m happy for folks to write up how close they came, and draw attention to it in the executive summary and in the read out, but to put a high likelihood says that you’re lame, and a high impact says you’re a chicken little. Don’t do it.

If you’re unsure, map out different attackers (n00b consultants with automated tools, script kiddies, organized crime, web app sec masters), work out how likely they are to succeed at the attack, and then work out what the impact is for each of these threat agents. Do the math and use the most likely choice with that most likely choice’s impact. Don’t under or over blow it – if a web app sec master could totally rip a copy of the database with both hands tied, the impact is likely to be low.

Lastly, don’t go the terrorist route. You are more likely to win lotto, fall out of your new private plane from 30,000 feet and then get killed by lightning than you are ever likely to be a victim of terrorism. Chicken little scenarios work once or twice, but you’re just wasting everyone’s time and scorching the earth for all those who follow you.

As security researchers, I think we’ve let down users in the quest to close down questionable and unlikely events. The problem is that even though unlikely, these events – such as MITM attacks – work nearly 100% of the time. They make great demos to scare folks who don’t understand what they’re seeing. It’s a shame that they just don’t occur in the real world all that often. So let’s move beyond “Expire it after 10 minutes”, and to a session manager that actually helps the business and makes users love you, and really close out some of these attacks.

The reasoning behind 10 minutes is a balance between the business (who’d prefer no time outs really and would love to have a magic “remember me” function that is somehow secure) and Tin Foil freaks like me who know how incredibly simple MITM, session fixation, and session hijacking can be. Many of the goals of our advice has been based on 1970’s standards and thinking, and 1990’s type of attacks that still work, primarily because we’ve been asking for the wrong solutions, like short time outs and don’t let users log on twice.

As Dr Phil says, “How’s that working out for you?”

So let’s think about ways to improve session managers to blunt the known attacks. We know that TLS has issues with MITM attacks, but we’re very lucky that this is a local attack (for now). Such attacks are also exceedingly unlikely outside of security conference wireless networks, and motivated attacks on behalf of organized crime (very rare but devastating – see TJ Maxx).

However, some of the other assumptions we’ve made when recommending bad ideas usually don’t think about the user of the application. My wife does all of our shopping online. The system is awful. It times out within a short period of time, and it usually takes 4 to 5 attempts to finish an order. I’m sure there’s some poor risk manager going “WTF? PCI is stupid – we have to implement 10 minute time outs for a process that lasts 30-40 minutes?” Let’s move beyond quick fire “gimme” penetration test results, and think about HOW the USER is impacted when we make recommendations with our consultancy hats on.

What goes wrong if it takes 40 minutes to assemble a shopping list? Do we have a financial loss? No. Do we have a reputation loss. Yes. Do we have a shareholder loss. No. Do we have a privacy impact? No. Do we have a regulatory impact? Only if you consider PCI DSS a regulation worthy of its name. What can we do to make it better?

With the online shopping example, losses start when we can order stuff. Easy! Keep everything intact (and allow items to be placed in and removed from the cart), but make the user re-authenticate to purchase or see their profile if it’s been more than 10 minutes. But with 100% of session managers today, that very act is impossible without significant customizations and we all know there’s some B List pen tester willing to ping you on long timeouts if you do write that secondary all singing all dancing session manager. THINK BEFORE YOU RECOMMEND RECEIVED WISDOM!

Realistically, we need to set some baseline parameters for every session manager.

• Strong. Session tokens should be random enough to resist being brute forced in a reasonable time frame. I still see this although it’s been solved on most platforms since 1996 or so.
• Controlled. Session managers should only accept their own session tokens.
• Session hijacking resistant. Session managers should rotate their tokens from time to time automatically. Every five minutes is fine, as is every request as long as there’s a sliding window of acceptable tokens to allow the most used button (Back) to work. All frameworks should possess a regenerate token API – it’s ridiculously hard in all frameworks but PHP today.
• Session hijacking resistant. Session managers should watch headers carefully and reject requests that don’t perfectly match up with previous requests. There is no reason for a user agent or a bunch of other headers (upto and including REMOTE_ADDR) to change within a session.
• CSRF proof. Session managers should tie themselves to requests, and check that the session and forms match up. OWASP CSRF Guard can do it, and realistically, this should be standard in every session manager.
• Cloudy Web Farm support. It’s very hard to do federated session state with most session managers, and yet the hackiest solutions I’ve seen for getting around this issue is due primarily to the isolated session manager mentality. There are good last writer wins replication mechanisms around, including “deliver at least once” – not everyone needs this functionality, but those who do really need it badly. This can be used as a pre-cursor to…
• Notifications. Most SSO products use work arounds so that the primary session manager times out before the SSO token does. This means that their are active SSO sessions you could reconnect to if you know what you’re doing. Let’s make it easy for folks like Ping to get notified when regenerate, idle, absolute and logout events occurs.
• Adaptive timeouts. Sessions that “expire” should be put into a slush pool, that comes alive again up to an absolute limit. But the instant that a user wants to perform a value transaction, the session manager should require re-authentication.
• Integration with common SSO protocols. SAML and WS-Federation are the two most popular SSO mechanisms out there. Realistically, all session managers should be aware of how these work, and tie into them strongly so that if folks use SAML/WS-Federation, this can be tied to the session token in use. How many times have we seen these two operate in completely separate worlds and then been a target for replay, session expiry and other attacks.
• Destroy means destroy. Make it easy for devs to do the right thing when the user clicks logout. Not only clear the session properly, but also all associated copies of that token – headers, cookies, DOM, etc, etc.

Notice that I didn’t put one of the lazy pen tester’s favorites in the above list – “Logging on more than once”. I REALLY don’t care about that. I care about what VALUE TRANSACTIONS you can do within the assigned sessions. If there’s a problem with value transactions, preventing two sessions at once isn’t going to save your bacon. Transaction signing / SMS authentication / re-authentication will help, or if it’s about resource consumption, then transaction governors like in ESAPI will help. THINK BEFORE YOU PUT STUPID THINGS IN YOUR REPORTS.

Many of these items are in ESAPI. That’s awesome, but it would be nice if all session managers dealt with sessions to support users and business uses, rather than obscure and unlikely attacks.

I thought recently about the ways in which folks who are looking for research projects in web app sec might make a useful contribution to the field. Part of that is the list of impossible tasks – those tasks that are so hard that it is unlikely to be solved in my lifetime. If you solve these, you’re a rocket scientist.

• Universal XSS Prophylactic – it seems simple enough – blow XSS out of the water. In all code for all time. We know how to do it well enough, but how do you solve it for all that crappy code still running? Think of a design pattern, injection, or mechanism that will blow XSS out of the water with minimal changes to existing code. Don’t say h().
• The No Injection Design Pattern. Almost all of our major commercially successful protocols are mixed data / program (i.e. not Harvard Architecture). Think about a design pattern, architecture, or API that allows ANY arbitrary protocol (SNMP through XML) to have no injections. This is not just about prepared statements, this is about taking an injectable grammar, and transforming it into a work of uninjectable beauty that is orthogonal and deep. There is previous work in this area (and you’ll be off to good start if you know who wrote it and include them in your research team).
• Common Off the Shelf Anti-Corruption Business Processes. Realistically, we’re here to support solutions, not enable security “features”. There’s no value to be had from security per se; we are the guardians against dumb luck and bad risk. There should be a open source business process library that is resistant to fraud, corruption, coercion and bribery, as well as just going from Step 1 to Step 10. Think of how a simple process of acquiring pens from the office supplies cupboard should be built compared to say acquiring a data center populated with 3843 servers. Or was that 3842 servers?
• Working with infected platforms. Financial institutions know that a certain percentage of their customers are infected with malware. At one institution I worked at, it was approximately 35% of a Certain Popular Operating System had at least one, and more often 10 or more different pieces of malware installed, ranging from hostile toolbars all the way through to Banking trojans. We knew absolutely that their computers would most likely steal their logins, and try to steal their funds. Think about ways you can perform “trusted” computing on a clearly untrustable platform. Booting a LiveCD is not going to cut it for my Mum. Think harder. This one will make you millions if not billions if you do it right.
• Creating a math or notation for access control that “proves” protection. This one is a big one. Many a time, we do code reviews and penetration tests and find insecure end points – client, presentation, controller, model, or data and we can exploit them. We shouldn’t be able to find these at all – your compiler and IDE should alert developers to leakage of secured data / functions. Come up with a notation or mechanism that can be easily parsed by compilers that helps prove that every piece of secured data and secured function is protected end to end. You must satisfy “principle of least privilege”, “default deny”, “fail safely”, and “complete mediation” principles.

Some of these items are dealt with by OWASP’s ESAPI, others by the judicious use of WAFs. But there is huge scope with billions of lines of legacy code hanging out there in any number of languages and frameworks. These are simply never going to be fixed, and yet we rely on them to keep the lights on, water flowing and sewerage flushing. Literally. These are the first five that I think are worthy of top class researchers. Go for it.

The Great Firewall of Australia is still being worked upon by the evil legal minions of Senator Conroy. At the time of writing, it’s not illegal to tell you how to bypass censorware. I’m hoping that the legislation has no retrospective provisions in it (which would be really evil).

Here’s how you get around censorship in case Australia decides to become a totalitarian state and block free and unfettered access to the Internet.

Free and pretty easy

• Tor. Install Tor into Firefox. Done.
• Anonymizing Proxies. This is the easiest path, especially if you don’t use Firefox. Find one that is hosted outside of Australia. There’s heaps available.
• P2P software helps transfer files around, but I only use this for downloading Ubuntu ISO’s. Seriously. Don’t breach copyright – it’s how I make a living. P2P is not particularly secure, and can be monitored and seeded by hostile entities.
• Most messenger programs allow file transfers. Again, don’t breach copyright. Most Messenger protocols are unencrypted and thus can be monitored, and realistically, how do you know the other party is not a dog? See Chat Roulette for proof of this principle.
• Most transparent ISP caches only work on port 80, and can’t work with SSL due to the way SSL works. Use SSL.
• Most transparent ISP caches only work on port 80. Go to sites on ports other than port 80, such as port 81, 8080 or similar.

Free, but might cost you your job

• Using head office’s proxy in another country. If you work at a large multi-national, use their proxy. Remember, most workplaces have anti-pr0n acceptable use policies, and they’re more likely to police them than Australia. Otherwise, Done.

Not free, but still fairly easy

• SSL reverse proxies. There’s a fair few of these services around. Done.
• VPN’s. Buy a Virtual Private Server (VPS) in another country, preferably the USA. Install OpenVPN, PPTP or IPsec on it. Done.
• Set up a local web proxy server that has child-parent caches. Set up a remote parent cache in another country, or subscribe to a remote cache service. Done.

There’s more ways to bypass this stupid proposal, but I’ll leave those off this list for now.

I seriously hope that there will be mass protests and heavy campaigning if there is any legislation tabled.

We need to show Senator Conroy that the government is truly misguided on this – voters unanimously don’t want to be censored. Parents don’t want it. ISPs and our entire IT industry doesn’t want it. The ALP support base hates it. Censoring Australia WILL lose the ALP power. It will allow all the tin pot failed nations on the planet to say, “We have the right to do this, Australia did it.”

We must resist this most evil proposal in any way possible. See you at the protests.

In the rush to release hundreds of publication specific apps as quickly as possible, every media dinosaur is desperately trying to claw money from the cashed up iPad owners with micropayments and pay walls. This is a recipe for disaster – and it’s going to be a gold mine for security consultancies, and nothing but tears for users.

Why?

All of these apps have to implement their own pay wall, subscription model, and store regulated financial data. Whereas before Apple did all the hard yards, now Flash web designers are going to be cutting code in Objective C for the first time to handle credit cards.

Are they going to get it right every time? Absolutely not. Will some of them get it right? Yes, those that get code reviews or have a skilled financial services development team. How many media outlets meet these requirements?

Mark my words, there’s going to be a lot of folks making money out of the poor decision to not create a secure micropayments service for iPhoneOS.

Australia developed polymer (plastic) bank notes from the 1970’s onwards, and they’ve been our currency since the 1990’s.

This bank note technology is essentially counterfeit proof – notes can have holograms, microprinting, a transparent window, “watermarks”, very colorful inks, metallic strips, and the notes are long lasting and machine washable. There’s a lot of positives.

The company that is formed by the Reserve Bank of Australia to print and market this technology is called Securency. They’ve been embroiled in a bribery scandal.

I just don’t understand how a company with a technological monopoly (it’s hard to figure out how to print on plastic) let itself be the conduit for bribes, particularly in the countries where the bribes are alleged to have occurred.

If I was a negotiator, and my opponent asked for a commission, structured deals, or outright bribe, I’d just report them to the head office, let them report to the other side’s local police, and then wait for the other side to appoint a new negotiator after justice has seen to be done. Their new negotiator would be so careful it would not be funny – you mean to do business, but the stench of corruption will not be tolerated.

We’re talking central banks here. Countries that have corrupt central banks are failed states – we cannot and should not be a part of these countries.

Like all financial institutions, the RBA and Securency employees and agents would have had to have undergone background checks, and yet many of their representatives and head office staff still committed a very serious crime – one punishable by jail time in Australia. Just remember background checks are an indicator of past criminal convictions, not future actions. Don’t waste money on them – just have strict anti-corruption policies in place, and walk everyone is tainted. The rest of the staff will get the picture more than a background check ever will.

For as long as I can remember, the standard “security” talk is a negative and destructive talk, where the presenter presents their latest “research” as if it’s going to solve world hunger, totally end the Internet as we know it, cure herpes, or put the spooks out of business as anyone could spy on the whole Internet.

The reality is that a few hours, weeks, or if it’s someone like Oracle circa 2005, years later, the problem is solved and we go back to giving our identities away for free on Facebook as if nothing had happened.

Seriously, why do we put up with this?

I believe it is because negative Chicken Little (“the sky is falling”) talks are much easier to do:

• Hand waving talks can be put together on the plane whilst going to the conference, or even later if you don’t hit the bar as soon as you get to the hotel. Talks of this type include “Why the IT Security industry sucks”, “This language is garbage”, “What you know is all wrong”, and my favorite, “PCI sucks”. These talks have zero merit because you can’t fix them. They’re opinion pieces barely better than a script kiddy blog entry, and are typically badly researched opinions rather than game changers.
• The buffer overflow, CSRF, Ajax, RIA, XSS, SQL injection, or latest attack with a twist talks are easy to do. You might need to start working on these talks at the airport lounge, but you’ll still pump out a talk. Patches for these talks are sometimes delivered before the talk has finished. The world has not ended.
• The fuzzing talk is is a bit harder. You have to run the fuzzer and let it find at least one badness. Probably a good idea to do it the night before you fly. Better yet, run it against a bunch of products in case someone did a good job.
• Developing new devastating attacks that can be blocked by CS101-level controls, like the magic pixie dust of input validation. What a complete WAFTAM.
• The pinnacle of negative talks has awesome demos, but realistically still demonstrates a paucity of ideas (such as how to detect if you’re in a VM – I mean really, who cares?). I have respect for these researchers, and really wish they’d apply their talents to good quality positive research instead of wasting their most productive research years on pointless baubles.

Why are positive talks harder? Because you have to work at them!

• Firstly, it’s about research, and original research is hard to do properly.
• Research takes time, and consistent application to an idea that may not even pan out. But if you don’t do it, you’ll never know.
• You have to find an area that is not yet solved. There’s a reason it’s not solved yet. These issues have made talented brains hurt already.
• You have to think of a new and novel solution to the issue, and the solution should be effective, simple and cheap. Most of the speakers on the party circuit simply don’t have this capacity, and haven’t had an original idea in years.
• You have to develop your solution and test it out against lab and real world scenarios to make sure it doesn’t suck. It helps if your solution is repeatable, your solution and code is documented, and its useable by others without sacrificing chickens.
• Many folks write papers and talks as if they succeeded at first go. That’s not science, that’s puffing up Brand Speaker. We learn from the paths not taken more than the eventual solution. Think about CSRF and session fixation for example – there’s heaps of folks who think CSRF is solved by a random nonce. But it’s not the entire story. Same deal with click jacking. Write up your failures as much you write up your successes.
• You have to hand your research and methods around to trusted peers to see what they think and hope they don’t spill the beans or steal your thunder. Once you’ve published, you need to make sure others can repeat your experiments and results.
• If you want to change the world, you have to give it away. You can’t patent it. You can’t tie it up in trade secrets. You can’t keep it to yourself. This is the hardest of all – think of the IT landscape today if AT&T had kept Unix to themselves. Exactly.

Lastly, and probably the most important – positive research and subsequent talks means sticking your neck out. Your peers evaluate what you’ve said and how your solutions work. If you’re not sure of self, this can be a huge risk to one’s ego. If you’re wrong, it’s real bad and you’ll be a virgin for another year. If you’re right, you will get {girls, boys, furries} and invites to all the sexy parties*

I will not claim that all of the hundreds of controls I documented in the OWASP Guide 2.0 are right. In fact, I know some of them are wrong. That’s how science works. At least I stuck my neck out and documented what I thought at the time. I’m happy to come back to the controls, do the research to find new controls that do work with minimal cost, and document those.

For those of you lucky to know me personally, you’ll know that I have no shortage of self, in fact probably enough self for two people, but you need it if you’re going to have a shot at this brave new world of repeatable, scientific progress in the web application security field.

I hope to see more conferences like OWASP’s AppSec Research conference, to be held in Sweden this year. Make sure you go to it. More importantly, stop wasting time on negative talks, and get moving on doing that research for next year’s conference.

* This is actually false advertising, as you’ll struggle to be invited to most conferences even though your research and talk will mean more long term than 100 negative talks. On the other hand, I’ve been told that Furries are easy to rub the right way.

I’ve just finished a job where I used OWASP’s Application Security Verification Standard as a light weight security architecture template.

The good news is that it helped us decide a bunch of controls (using ESAPI of course) that will hopefully improve the security of the application. I’ll find out in a few months if any of it helped.

What worked: pretty much everything.

What didn’t work: Some controls are not relevant to some classes of application. Do your homework before you go into the meeting so you can skip over ASVS controls that simply can’t work.

We found that there are controls we discussed that aren’t in the ASVS. The ASVS is a 80%/20% (Pareto principle) standard as pretty much all apps come from such a low basis today, so any security improvement is a worthwhile improvement even if it’s not milspec. I wasn’t too fussed that we missed a few key items.

For those of you floundering around trying to figure out how to do Security Architecture reviews, ASVS can be your friend!

Hilarious fun for all the family. Google’s GMail service has been blacklisted by an ORBS product.

These ORBS places are run by dumb ass vigilantes. The Internet just doesn’t need wanna-be-cops who have no legal basis for their operations. Just in case you’re wondering, I’ve been blacklisted by similar morons in the past and simply couldn’t get off their stupid lists, despite NEVER being a spammer and only sending maybe 30 messages a day from my host. Greebo, my not so clever cat, has more spam spidey sense than these oxygen bandits will ever have.

So here’s the transcript:

“Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 Rejected 74.125.83.43 found in dnsbl.sorbs.net (state 13).”

Let’s look that IP up, as it’s not mine:


% nslookup 74.125.83.43
...
Non-authoritative answer:
43.83.125.74.in-addr.arpa name = mail-gw0-f43.google.com.


FAIL.

Good luck getting off that list, Google! Let’s see if your billions of dollars and many lawyers will make it happen where my pleas fell on dumb ears.