Secure Coding Course

Key resource
OWASP (Open Web Application Security Project)

The Information Security Team (IST), in conjunction with the IT Services Learning Centre provided professional training in secure software development based on the Certified Secure Software Lifecycle Professional (CSSLP) course. Their aim, to promote secure software development across the University.

Topics addressed included:

• Secure Software Concepts
• Secure Software Requirements
• Secure Software Design
• Secure Software Implementation/Programming
• Secure Software Testing
• Software Lifecycle Management
• Software Deployment, Operations and Maintenance
• Supply Chain and Software Acquisition

The course introduced new concepts, and reinforced existing concepts within security and software development, overlapping closely with Information Security best practices and frameworks such as ITIL.

Overall the course made us aware of common security threats and principles of how to incorporate good security practices in to every element of the software development life cycle.

Areas covered of particular interest included:

• The most critical web application security risks. Did you know SQL injections remains the top security flaw in web apps, and has been for the last 10 years.
• Types of threat. We are aware and try to be on guard against ‘black hat hackers’*. These (external) threats are very real. However, internal threats are equally prevalent. These can be malicious users or (more often) general user usage causing errors or just doing something the developer didn’t expect.
• This incorporates the whole business. When it comes to security the whole business is involved, from users to business strategy. Where there is unawareness of the risks IT need to help guide business policy and processes and help educate users. This, of course, relies on IT knowing themselves.

There was a lot to take away from the course and much to process, but in short we should develop expecting to be attacked.
There is always room for improvement, however, fitting this into an already busy workload is far from easy. Advice given of how to approach this was with lots of small steps. The Deming cycle (Plan, Do, Check, Act), is just one example of how to address this. There’s nothing new in the advice here, but only to emphasise be realistic!

---

As an amusing end note as a warning. It’s all too easy to invest in security yet fail in your objective if you do not look at security holistically.

Take the following example.

Here is a car park security barrier unit. It has four components:

• The barrier arm
• A pass reader (the box below the barrier)
• A weight sensor (in the road above the barrier)
• Bollards (to the right of the barrier)

The security barrier unit functions exactly as it was designed to do. The barrier is in place to prevent unauthorised access. The barrier raises only to let cars in when a valid pass is presented to the pass reader, or to let cars out when the weight sensor is triggered. There is a suitable timing delay on the barrier to ensure cars cannot tailgate. The bollards are there to prevent cars avoiding going around the barrier.

… is the security working?

*A black hat hacker is a hacker who violates computer security for little reason beyond maliciousness or for personal gain.