Secure Development – How Protected Are You …

First up - after my last posting, someone that works in the security field contacted me to let me know that I should be referring to folks that try to exploit weakness within systems and to break in to systems are known as crackers.  I stand corrected.
 
Last time we chatted, I discussed the need for security.  Today, I’d like to expand on that topic and talk about the need for secure development.  The need for development teams, and the software development lifecycle, to account for security is more critical today than it has ever been.  In fact, as more and more of our devices live in an always on/always connected state – the risk to you and your data will only increase.   Many organizations spend time and dollars to buy physical hardware to sit on the edge of their networks to protect their data centers - but then forget to build security in to the software that they implement in to their production environments.

How many of you over the last several years have opened up your firewalls to allow staff members access to your systems from their laptops, their mobile phones and their tablet computers?  Using internally developed applications companies are exposing their systems and data to be used from anywhere, anytime.  While this increases the productivity of your teams, it dramatically alters your security stance and increases the likelihood that the bad guys will find a way in to your organization.

As stated in the last posting – Microsoft used to be the poster child for products riddled with security holes that crackers played with like Swiss cheese.  There didn’t seem to be a day that passed where I was not hearing of some new exploit against the MS-Office products, Microsoft’s server products or Internet Explorer.  It finally became embarrassing enough to the company that in early 2002, Bill Gates sent an email to every employee of the company to layout the strategy of developing applications that were hardened against the hackers.

This event was not only a pivot point for Microsoft, who now has a pretty good reputation in the industry for developing hardened applications, but for the industry as a whole.  It became common for companies to talk about the processes they were using to develop secure applications.  In fact, development lifecycles were modified to incorporate security concerns/risks in at the beginning of the process and to track them just like any other requirement for the software.

If you have development teams on staff or on contract, on-shore, off-shore or near-shore, you need to ensure that you are building security in up-front in the process.  That means training your development teams on the concepts of secure development processes, design reviews that review all of the business and security requirements, threat modeling, static and dynamic analysis of the generated code, penetration testing and ensuring that your test cycle takes in to account security.

Here, I will harp on the need for development teams to build unit and integration tests up-front in the cycle that will not only hammer the system from a functionality standpoint, but will also attempt to break the software and test the ability of the application to secure data and ensure that they are not opening back doors for intruders to use to gain access to the systems.  These tests need to be constructed in a manner that they can be added to the larger pool of regression tests and live with the code through its lifetime within production.

Can you look across your code base and answer the following questions:

1. Is my entire code base subjected to nightly or weekly builds with automated unit, integration and regression testing in place?
2. How often am I reviewing the test cases to ensure that they are up to date and address security risks?
3. What tools do I have in place that allows me to know that my entire code base is being tested – code coverage?
4. Do the tools that I use allow me to identify and report on the most common security risks?
5. Do the tools that I use provide real-time or near real-time feedback to the development team identifying where issues were found and what remediation steps are needed.
6. If I have the tools in place – are they actually being used and is someone held accountable to follow up on errors/issues that are found by the tools?
7. If I have the tools in place are metrics exposed to the management team?

No one solution works for every company and every development team.  I’m not going to sit here and point out specific products that you can or should use – that’s for you and your teams to work through.  What I am saying is that if you haven’t started this conversation, you are late to the game and you are potentially exposing your organization to huge risks.

While it is all good to discuss the tool sets, you also need to work on the mindset of the organization.  From the CEO on down, management needs to understand the risks that exist and the costs associated with the change in process that will secure your applications.  Additionally, they can’t be sold a bill of goods – do not make promises that you will magically eliminate all risks.  What you are doing is raising the bar and making it more difficult for the cracker to get in to your organization.  Again, going back to the last post – 79% of all attacks on an organization were targets of opportunity.  Meaning, the companies in play did not pay attention to industry best practices and literally left the doors open for the crackers to walk thru.

I’ve seen companies successfully deploy off the shelf solutions, open source solutions and a mix of the two to meet the security challenges of software development.  Your challenge is to find the mix of solutions that will allow you to meet the needs of your software development lifecycle and the threats and risks of the systems you develop.

What actions can you take to improve the security stance of your software development lifecycle?

If you'd like more information on my background: LinkedIn Profile

Relationships are Messy – with a capital “M” …

I recall several instances in my professional career where my frustration with individuals lit me up.  Sometimes, it was my boss, sometimes it was people that reported directly to me, sometimes it was peers.  It’s not their fault – it’s not my fault, it’s the nature of human relationships.  Sometimes the person you get along with today is the person you’re battling tomorrow.  It’s taken me a while to figure out that I need to check my emotions at the door (and, yes, I’m human and still battle the tendency to react first).

Several years back, I was working in a large organization.  We had offices across the United States and were having problems with the company that provided the networking backbone for the organization.  This was becoming critical as they had missed several deadlines to increase the capacity of the network and upgrade key infrastructure at the main hub points of our network.  This was having a direct impact on our ability to transfer key data between the various locations and was beginning to have a direct impact on our sales and marketing organization due to the fact that they could not rely on the data and software packages used to manage pieces of their business.

At one point in the process, we were having a meeting between the key individuals responsible for moving various phases of the project – both internal resources and external resources.  I knew all of these people quite well.  We had all worked together across a period of several years.  I knew that nobody was intentionally holding things back and that for the most part we were all trying to move the ball forward.  However, I let my emotions get the best of me that day and let my frustrations show in the meeting.  As I ran the meeting, I ended up accusing several people of intentionally missing key milestones.

After the meeting – a person that I considered one of my mentors pulled me aside and sat me down for a conversation.  One of the first statements she made was, “You can catch more flies with honey than with vinegar.”  She patiently let me go off on a tangent about my frustrations and then reeled me back in to reality.  She began asking me questions about the project – who was doing what, what might be causing the delays, and if I really believed these individuals were intentionally causing the delays.  It was easy for me to see that I had crossed a few boundaries and, in the heat of the moment, had damaged relationships that I had spent years building.  She also made me realize that it was my job to help these individuals remove the roadblocks that lay in front of them.  I wasn’t there just to listen on what was happening and to report it up the chain, it was my job to add value to the process.

Mea culpa!  Mea culpa!

I then spent the rest of that day and the next going around to each of the individuals in the meeting and apologizing for the behavior that I had shown in the meeting.  If I was going to make things right with the folks that had sat around that table, they had to know that I was sincere in apologizing for the behavior that I had shown.

Ultimately, we got the project completed and all was right in the world … I also learned a few lessons along the way on why I needed to keep my emotions in check.  It was my responsibility as the person leading the project to actually listen to what each of these individuals was saying and then use my skills to remove the roadblocks that they were experiencing in attempting to manage their tasks.  As the person leading this project, these people had the expectation that I was there to help.  I was not there to throw additional impediments in their way or to increase their workload.

Sometimes, it is easy to let the pace of activity overtake us and allow ourselves to forget why we hold the positions we hold – to add value to the process, the team and the organization by removing obstacles and creating the momentum to carry people forward.


If you'd like more information on my background: LinkedIn Profile