We are more than happy to welcome Chris Wysopal, (also on Twitter) as the next security expert on our blog. Chris, the CTO of Veracode, is one of the key influencers in IT security today. He is a regular speaker at conferences such as Black Hat or the RSA conference. From 2012 he has been also member of the Black Hat Review Board. He was named one of the Top 25 Disruptors of 2013 by Computer Reseller News and one of the 5 Security Thought Leaders by SC Magazine in 2014.
Chris Wysopal: I started my career as a programmer. I built desktop business software for a few years and then started to explore the internet. I joined a startup building a multi-user, multi-role, internet connected application server. Thinking about all of the security risks was a challenge to design and build. To me this was a very challenging part of software engineering. That company was ultimately not successful so I decided to take a full-time job in security to see of I would like it. I joined Bolt, Baranek & Newman (BBN) in Cambridge, MA. They created the first long distance network ARPANET and were an Internet backbone provider when I joined their IT security team. I got a well rounded experience with network security, incidence response, secure system design, and pen testing. To me it was fascinating and I was hooked. I decided to specialize in software security as I could leverage my knowledge of programming.
CW: Yes, most data breaches and system compromises can be traced back to a vulnerability in software. About the only attack that doesn¹t involve a vulnerability is when you trick a user into giving up their password. So why is the vulnerability density so high that every piece of software has so many it is easy for attackers to find one and use it. It really comes down to businesses not paying any price for shipping or operating highly vulnerable software. The software manufacture has no liability. The end user ends up with the cost. We need to expect more from our technology suppliers and not acquiesce to statements such as “all software has bugs” and “we can’t give you great features in a timely manner securely”. It is simply not true. Best practices today do not slow down development and while not making software perfectly secure can create significantly more effort for attackers to meet their goals. Not everyone is Apple with a billion devices to protect but the fact that a zero day in iOS is trading for up to $1.5M shows they have raised the bar significantly on attackers.
CW: We want to be an example for our customers both big and small. We have customers 200 times our size and customers that are smaller. We back security into our SDLC as early as possible so there are no surprises when it is time to release. We scan code today in our nightly build process and are moving to scanning pre-checkin on the developer’s desktop. Finding flaws as soon after they are created makes them much cheaper to fix and barely impacts the schedule. Finding issues right before release always impacts the schedule. We also have the concept of ‘security champions’ who are developers that have taken extra training and meet together regularly to do exercises such as capture the flag and threat modeling. These champions become the eyes and ears of the product security team embedded in every development team. They can notice when new security critical functions are added and initiate focused code review or threat modeling or design changes at the appropriate time so these processes are done as early in the lifecycle as possible.
CW: This is a very hot topic. All of my customers are asking about this, even 100 year old banks. I believe most software development will move to DevOps over time. It is in small pockets in some companies and some companies are moving wholly to DevOps over the next year or so. Application security must become as automated as possible and fit into the development pipeline from IDE and version control to continuous integration to continuous deployment and monitoring. As application security people we need to fit into the way the developers work, not vice versa. Sure out of band manual pen testing can still be performed but automated testing along the SDLC becomes mandatory. An important aspect of this is the finding of the security testing tools need to be inserted into the developers defect tracking system, such as the JIRA ticketing system. To go fast defects need to be in one place to make life easier for the developer.
CW: Security education through eLearning or instructor led training is important but I am seeing good learning happened more on the job. One place this happens is in the IDE where a developer can get an alert that their code looks risky and there are suggestions. That tight feedback loop on their own code promotes learning. Another place I see it is developer coaching. This is when a developer has a question about the best way to fix something and an Application Security Consultant can get on a WebEx and review the code side by side with the developer and the dev can ask questions in a judgement free zone. A coaching environment is great for learning.
CW: Unfortunately I don’t get much time for this. We do have an activity we do at Veracode called The Veracode Hackathon. We do this twice a year. We give all employees 3 days off from regular duties to work on a project which might be business related such as adding a new feature to our analyzer or it could be completely non-related such as building a potato cannon. One of the last hackathons I decided to learn SDR and GNURadio. I was able to capture my car’s remote door opener and decode the signal to the bits. I ran out of time before I could implement a replay attack. On the work technical side sometimes I will speak with our customers about the best way to fix some vulnerable code or do training around secure coding in the SDLC.
CW: Learn the basics for a good foundation. Install Linux and compile some programs from source. Learn TCP/IP networking well enough to configure some routing rules and firewall rules. Building your own gateway box for your home network is a good thing to do. Then learn some of the attack tools to get a feel for how the attackers operate. Use metasploit, SQLMap, and crack some passwords.
CW: Well of course I still use netcat but perhaps nmap is my favorite. Attack surface enumeration is an important part of understanding how to attack or secure something and nmap is a great tool for that.