I had the honor of being interviewed by Michael Fornal for his blog “Fighting In.Security”. He has just posted the interview here if you care to check it out. Read some of his own writings while you’re there. It’s more interesting than an interview with me.
July 28, 2011
June 20, 2011
Web App Sec Cheat Sheets
Posted by andyitguy under information security, Web App Sec | Tags: Veracode |Leave a Comment
I’ve never been one to use my blog to link to vendors and or their products but I received an email last week that was intriguing enough to get me to take a further look. I liked what I saw and decided to pass it on. It’s nothing earth shattering or new just some good ole common sense that we can pass on. One thing that I have come to realize as I work more and more with developers is that there really is a lack of understanding in how to write secure code. It’s not taught in school and many businesses and development shops are more focused on getting code written and out the door. As a result of this we see the same basic things pop up again and again and again. At work we see this as we review new code that is hoping to be put in production. SQLi, XSS, XFS, etc.… it’s like security groundhog day. You find it, get it fixed, tell the developers how to avoid it and start all over again. Much of this is due to developers being project oriented and many time they are contractors who come in long enough to write their piece and then move on. So what you taught them may never come to fruition for you.
Anyway, Veracode has put together 5 cheat sheets on common coding issues and they are pretty decent. They explain the problem, what it does, why it’s bad and give you some tips on how to avoid it in your code. There is also video and sample scripts and code for you to look at. It may not be anything for you but it is something that you can pass on to the developers that you support or work with. Who knows it may save you some time and headache as the number of issues is reduced because you took the time to pass this on.
• SQL Injection: http://www.veracode.com/security/sql-injection
• Cross Site Scripting: http://www.veracode.com/security/xss
• Cross Site Request Forgery: http://www.veracode.com/security/csrf
• LDAP Injection: http://www.veracode.com/security/ldap-injection
• Mobile Code Security: http://www.veracode.com/security/mobile-code-security
March 24, 2011
One of the things that we are faced with is meeting goals that often change depending on lots of different things. Current threats, business goals/needs, projects, etc… We all have the ultimate goal of securing the data and systems that we are responsible for, at least I’d hope that we all shared that common goal. How we go about this varies greatly, again depending on lots of different factors. I’m not one to criticize someone for doing their best but I will point out areas that I take issue with. Especially when I feel that they are doing something that ultimately will cause larger problems or are making statements that I consider to be detrimental to security, others, or even just themselves.
I ran across a blog post the other day that caught my eye due to the title “Mitigating OWASP top ten without any code.” So I saved it to read later since it is relevant to my interest and potentially to doing my job in a more efficient way. (not that I code. I tried my hand at that many years ago and discovered that I don’t think like a coder and would be miserable and probably very bad at it). But I am responsible for protecting sites, apps, and systems that are potentially impacted by the OWASP Top Ten.
As I read the post it both impressed me and made me scratch my head. I know that the author says that these things have and are working for them and I think that is great. I’m not sure that I would have done it the same way and when you add all of these things together it could be quiet costly to implement. I do love the fact that it does implement defense in depth which is still very important. The more hurdles an attacker has to jump over the less likely he is to keep after you.
What really bothers me about all of this is the final paragraph.
All the key controls are implemented in the infrastructure. Developers can be left to coding the functionality and improving performance.
I have a hard time with this because it gives developers a free pass. Don’t worry about writing better and more secure code just finish quicker or add more “features” so we can market them to increase sales. It also allows poorly written code into production where it is vulnerable to new attacks and also the potential failure of one of your layers of defense. Are you going to fail closed if something fails and risk shutting down the site/app until it is fixed or allow access to insecure code with no protections in place (Just like the old days).
If we continue to allow (or encourage) poor coding practices then we will always be behind the curve and playing catch-up with the hackers. I’m all for infrastructure protections but not if it means we give developers a pass on writing secure code. I know code will always have errors and vulnerabilities in it just as infrastructure and other areas where we implement protections will always have their shortcomings.
The very last part of this post does give a little hope though.
The security controls can also be implemented at a company level, with minimal security involvement required per project. Is it just that when all you have is a hammer, everything looks like a nail or is this truly a better approach?
It shows that they realize that their solution may not be the best or only answer and that they are open to suggestions. So my suggestion is train your developers on secure coding practices while implementing these other controls so that one day you may just be able to reduce the number of total controls because your software is well written.
February 21, 2011
Why does Web App Security continue to stink?
Posted by andyitguy under information security, Web App Sec[8] Comments
Everyone and every company has a web site now a days. Some are professionally done, some are made from DIY kits provided by the hosting provider and some are done from scratch by someone who claims to know what they are doing. It doesn’t seem to matter who built the site most all of them have a common theme. Insecurity.
A joint survey and report by Barracuda Security, Cenzic and the Ponemon Institute that was released earlier this month confirms what we already knew. Web App Sec is still in the toilet. It’s high on everyone’s list of priorities but little is being done that actually makes a difference. OK, so that’s not exactly a fair comment. Lots of things are done that do make a difference but they only solve part of the problem. The problem is epidemic and multi-faceted. When you look at some of the numbers it’s enough to make you get angry, cry and pull your hair out all at once.
I have my own opinion of why web app security is so dismal. It’s due to lots and lots of factors.
- Poor development and coding.
- Reusing insecure code.
- Inadequate testing.
- Improperly configured web sites.
- Improperly configured web servers.
- Improperly configured network devices.
- Insecure architecture.
- Lack of policies around all of the above.
- Lack of understanding of the risk by management, IT and even those responsible for security.
- Lack of understanding of the effectiveness of controls.
- Only doing enough to “check the box”.
- Following the advice of a consultant or vendor who doesn’t take the time to truly understand your needs.
- Buying a solution that is sold as the “answer” to your security problems.
- Relying on your hosting provider to take care of security.
- Not using defense in depth.
This list isn’t comprehensive but covers a lot of the bases. A lot of the security issues arise out of a lack of understanding of the problem and assuming that the advice of someone else (consultant, vendor) is going to keep you secure. It’s because companies are rolling out web based applications faster than they realize. When you don’t even know how many web apps you have you have bigger problems than not knowing how to secure them. You have process and procedure problems that need to be addressed. When you are deploying web apps at a rate that outpaces your ability to secure and monitor them then you have resource issues that need to be addressed. If you have resource issues then you probably also have a skills and training issue that needs to be addressed.
Security isn’t so hard that it can’t be done it’s just that it’s not important enough to be addressed seriously. It has been ignored for so long by so many that the problem has gotten out of hand. A company that brings security into the picture after the network is in place and apps have been deployed and now web apps are being deployed is already way behind the curve and playing catchup is never easy. It requires changes that may will break things. It requires money and inconvenience for users.
So what’s the answer? It’s not easy and unfortunately it requires lots of time and patience. It slows the release of new features and endangers deadlines. Things that most companies are not willing to put at risk. It requires that we spend money in places that provide no tangible returns. It requires that we change the mindset of the organization and our users.
Ultimately short of starting everything over and doing it right the answer lies with each of us doing what we can to secure what we are responsible for and to educate ourselves and those we work with. Create an agenda and plan and work with Management, the business, IT and your own security team to ensure that all are aware of the real problem and that all work together to make it better.
January 10, 2011
To quote @Armorguy….
OMG! OMG! OMG! OMG!
A little over a year ago Martin Fisher (@armorguy) and I decided to start a security podcast. We invited our “News Yankee” Steve Ragan (@steved3) to join us and we started recording. We knew only a little about podcasting and we knew that we wanted to do something a little different from most of the other security podcasts out there. We decided to focus on areas that we knew best which are leadership, management and operations. As time went on we decided to add a “young whipper snapper” to the crew and Joseph Sokoly (@jsokoly) joined us. We’ve had a blast doing it and enjoyed interacting with listeners and with our guests. One thing that we never even considered is that a year later we would actually be honored to be listed as one of 4 finalists in the Social Security Awards for best security podcast. We I read the post from Alan Shimel my heart stopped and jumped all at the same time. Especially when you see who the other finalists are.
WOW! what company to be in.
Obviously we would absolutely love it if you would vote for us but even more importantly keep listen (or start if you haven’t been) and tell your friends about us.
To cast your vote you can do so from this link.
January 4, 2011
You say false positive, I say tell me anyway
Posted by andyitguy under information security | Tags: exploits, Pen Test |[2] Comments
One of my favorite people on the intertubes is Shrdlu. I’ve enjoyed reading her enlightening and somewhat amusing posts for quiet a while and have bantered back and forth with her on Twitter many a time. She was even the first interview that we Martin did on the SFS podcast back in January of last year. Unfortunately I have yet to meet her in person and do look forward to finally getting that honor some day soon. (You aren’t coming to Cincinnati any time soon are you?)
Anyway, She started the New Year off with a post about bloated Pen test reports. Things that are actually there but most likely are non-issues. They aren’t currently exploitable and quiet honestly probably never will be. Especially when you take into account other processes and such that help to mitigate them. I agree with her opinion that they do make the report a pain the the rear when it is presented to management. They then want the problem either fixed or a good explanation as to why it isn’t an issue. Both of these take time and energy that can be better spent in other areas where there are real issues to be dealt with. Often time it’s easier to have the problem fixed than to explain it to management. 
Where I do take issue with her is that I do want to know about the finding. I’d like a addendum to the report that tells me these are the things that we saw that you should know about but not worry about at this time. Things such as this usually are easy to fix and can be passed on to the development team (or whatever team is appropriate) to be fixed in future releases. Plus it gives you a list of things to keep an eye on later on. As we all know it may not be exploitable now but who knows what the future holds. I’d rather have the info so that if there is a need at a later date I know that I have to address it now rather than wonder if I’m vulnerable to it and only find out when it hits my systems.
January 3, 2011
Right results are not the measurement of success. How you arrive at the results is even more important. It is not all about results. Of course results are important, done the right way.
For quiet some time lots of us in the community have been saying that the industry is broke and that we’re looking for ways to fix it. Unfortunately I don’t have a fix yet but this quote sure sums up the problem. The problem is the band-aid approach to securing our networks, applications, environments, data, etc.
When a threat arises or an attack happens we fix it. Then we move on to the next thing and that is OK. It has to happen that way because of the nature of the beast. We are constantly under attack and finding new flaws. The business is driving us to “fix” the problem but they see the symptom as being the problem. Sure that are some who realize that the issue at hand is a symptom but they then assume that by going up one or two levels that they have found the problem and demand a fix for it. Rarely (or never) are they right.
Security professionals tend to think this way as well. They focus on the here and now and not the root of the problem. We measure our success by “right results”. A virus hits and we remove it; we have a “right result”. A worm is running amuck on the internet and we block it from entering our environment; we have a “right result”. We get hit with a XSS or CSRF issue on our web site and we fix it; we have a “right result”. We buy a new technology that does this or that and we have a “right result”.
All of these are good and necessary. They have to happen but they aren’t enough. Sure they help ensure that we stay employed because someone has to stop them and fix them. That is about all it does though. It doesn’t address the real problem of how do we truly secure what we are responsible for.
The last part of this quote is very important. “How you arrive at the results is even more important”. I’m not looking at this from the perspective of how did you remove the virus or stop the attack. I’m talking about how you are strategically protecting your environment. Are you doing it with one band-aid at a time or are you really deploying a solution that will meet your needs today and in the future? Are you looking at the big picture and working with the business as a whole to solve the problem?
Of course the answer isn’t that easy. If you are in a small environment you are often the only person responsible for technology or one of a very small and very busy team. If you work for the enterprise you may face the same problem or if you are fortunate enough to work where there are lots of technology and security professionals they are usually divided up into various teams that are busy and often working against each other to achieve different results. Then there is the whole dynamic of getting the business on board. They don’t understand or sometimes don’t care.
Unfortunately there is often little we can do alone but if we keep focus and continue to sharpen our skills and understanding then we can slowly start to change things.
December 22, 2010
It’s been quiet a year for me and my family. Lots and lots of changes and I’m glad it’s almost over. Due to the busyness of everything that has been going on my blogging has suffered greatly. I’m talking about the quantity of posts so keep the quality remarks to yourself. 
Even though I haven’t blogged a lot I’ve still been letting my thoughts on what’s happening in the industry be know via the Southern Fried Security Podcast with my good friends Martin, Steve and Joseph.
I’m also planning to move the hosting of andyitguy.com to another site soon and as I was preparing things I noticed that I’ve posted 666 entries to the blog. Not a good number to end the year on so I had to take some time to get at least one more blog in before 2010 leaves us. For those of you who do care I hope that next year I will get back into a regular rhythm of blogging and post at least once or twice a week.
I hope 2010 has been good to you and that 2011 is even better. I thought I’d leave you with this YouTube video that Marc Handelman posted on his site today.
Merry Christmas and Happy New Year!!
November 11, 2010
Today is Veterans Day in the US. A day when we stop to say a great big
THANK YOU!!!!
to all of you have have served or are serving in the military. I’ve got lots of friends who served and some who are still serving. I know it’s not a easy life especially in the last several years.
As the old saying goes “If you live in a free country, Thank a Veteran!”
November 10, 2010
Fishing for Zero Day
Posted by awillingham under information security, malware | Tags: Zero Day |1 Comment
I miss the interaction that I used to have on Twitter. Now that the only way I can get it during the day is via my phone it is much harder to follow and participate in the conversations. Recently I’ve been trying to do a little more but with limited success. Then last night I posted a query looking for stats regarding malware infections on fully patched systems w/ up to date AV signatures. Man did I land a big one. Josh Corman (@joshcorman) of the 451 Group apparently was hovering about 10 feet deep next to the ole oak tree that fell in the lake last year. As soon as the lure hit the water he had it and was off and running. We ended up having a pretty decent conversation about this and he gave me some good stuff for a report I’m working on.
Then today I posted the following question on Twitter:
What is your definition of a zero day?
It had barely hit the Twitterverse before Josh was off and running with it again. We ended up trading a few DM’s and it went so well that I posted the question again and this time it landed in a school of large mouth Bass. They were all over it like white on rice. I’ve included them below for you to see. Most of them were keepers but a couple were too puney to keep so I threw them back.
Why did I do this and why do I think it’s important? I did it b/c of a conversation I was in at work. There was a little disagreement on exactly what a Zero Day was and I wanted to get the input of those who follow me on Twitter. They are men and women who know security from many different angels and I wanted to see what kind of similarities and differences I would run into from different perspectives. I also was hoping to spur conversation. Conversation is key to making security work in the big picture. That’s why I find so much value in participating in Twitter. I love how Security Professionals have latched on to Twitter and use it as a venue to have good solid conversations.
I’ve added a few thoughts of my own under some of the tweets. So feel free to read along and if you want to join in please do. Tweet me @andywillingham, email me andy dot itguy at yahoo dot com, leave a comment on this post, or blog it on your blog.
lonervamp
@andywillingham I also don’t really use the term outside other sec geeks. It’s otherwise always "unpatched vuln. exploit in wild."
The term has a good FUD factor for Senior Management
>
lonervamp
@andywillingham I *do* get how some define 0day with the key phrase "previously unknown," however. Either by vendor or public/defender.
»
Wim Remes
@andywillingham release of working exploit code for an unpatched vuln, optionally with a side of narcissistic wanking.
»
lonervamp
@andywillingham my POV is of defense or even attacker. I don’t much care if the vendor knows. I’m still at risk as if they didn’t.
»
lonervamp
@andywillingham 0day: a vuln without a patch or official fix. So even if known, it’s 0day to me until official response.
It’s hard to patch what doesn’t have a patch
»
bug_bear Tim
@andywillingham Media Hype for a unpatched vulnerability being exploited.
If it wasn’t for the media the term “Zero Day” probably wouldn’t have caught on.
»
WeldPond Chris Wysopal
@joshcorman @andywillingham AV industry calls 0 day malware "custom".
Sounds like “The Spin Zone” to me
»
joshcorman Joshua Corman
.@andywillingham I "love" how we think Vuln 0day is sexier. Since AV is so reactive isn’t most malware ~technically~ 0day?
At least most new malware, even if patch is out if it’s not deployed it’s not doing much good.
»
timdafoe Tim Dafoe
@joshcorman @andywillingham Must it truly be "actively exploited"? What about an unused working exploit being held in reserve?
»
wikidsystems Nick Owen
RT @andywillingham: Not one else has a opinion on what a zero day is? < the conference day when the press release goes out?
there is a lot of truth in Nick’s statement
»
armorguy Martin Fisher
@andywillingham Zero Day??? Hmm… Wasn’t that Elvis Costello’s second album? Or was that CCRs? I forget…
This is one of those that I mentioned being puney. 
»
negativeindex Donald Rudder
@andywillingham sorry. Vulnerability being exploited but not disclosed to the wider security / user / vendor community.
»
pjvela PJ Velasco
@andywillingham I would say a zero day is the announcement of a formally unpublished exploit that makes use of an unpublished vulnerability
This is where some start to split hairs. We have a exploit and a vuln but they exploit may not be in the wild.
»
JoelEsler Joel Esler
@andywillingham a vulnerability previously undisclosed and in use. Without it being in use, it’s just a disclosure.
I like Joel’s thoughts about the difference between in use and disclosure.
»
pauldotcom Paul Asadoorian
@andywillingham The day before 1
»
joshcorman Joshua Corman
RT @andywillingham: What is your definition of a zero day? <- Active exploitation of a previously unknown/unpublished Vulnerability
