Security Matters – And It’s Not Going To Get Any Better …

If you have any type of a system interface that is exposed to the internet, then you have a potential problem.  In case you haven’t heard, there’s a war going on and you had better be making sure that your defenses are in place and being kept up to date.

What used to be the realm of script kiddies playing with ways to hack in to a system for fun has grown in to a full blown international business with hackers stealing real money, downloading corporate data, or turning your systems in to a swarm of botnets that can be used to hack in to other systems across the world.  The landscape isn’t getting any prettier with governments now openly accusing each other of state sponsored hacking.

Today, one of the most sought after positions is the role of a security architect/analyst.  These are the white hat hackers that work to keep a company’s systems and applications safe.  In today’s world, I wouldn’t ever make the claim that they can fully protect you, but, if they’re doing their jobs, they’ll dramatically lower the chances of your systems being successfully attacked.

And, these days, you have to be just as concerned about internal hacks as you do about the potential for someone outside the company to perform the hack.  If you are hacked, the chances are far better that you’ll be hacked by some outside party, but that doesn’t remove the threat of a disgruntled employee leaving a back door open so that they can clean you out down the road.  According to the 2012 Verizon Data Breach Investigations Report, they found the following:

• 98% of the data breaches were initiated from external agents
• 4% involved internal employees
• 58% of all data theft instances were initiated by activist groups

See the following link to read the entire report: 2012 Verizon Data Breach Investigations Report

The report is sobering to say the least.  The most damning piece of data from the report: 79% of all attacks were targets of opportunity.  Meaning that the company impacted left the doors open by not taking proper precautions and securing their systems and applications.

I’m not going to use this space to regurgitate the findings from Verizon’s report.  What I do want to do is spend a few minutes discussing the relevant point in time to talk about security.

That would be NOW!

Ok, let’s break it down from the beginning.  Within whatever methodology you are using to run your projects and manage your SDLC – you need to incorporate security up front in the process.  Within each project you need to be aware of the security risks and take appropriate action.

1. What are the risks associated with the project – hardware, software, interfaces, data, etc?
2. What is the likelihood of each risk occurring?
3. What is the mitigation plan to remediate the risk?

These questions need to be asked up front and security needs to be built in to the requirements/stories that the team will use to build and test the solution.  That’s right, you not only need to build the requirements upfront, you need to test them just like any other requirement.  Moreover, there are industry best practices to follow at both the physical infrastructure/data center level and the application level:

Data Center Best Practices

1. SAS70 Data Center Security
2. Best Practices for Data Center Security
3. 19 Ways to Build Physical Security into a Data Center

Application Security Best Practices

1. OWASP Web Application Security
2. Microsoft Security Development Lifecycle
3. ISC2 Ten Best Practices for Secure Software Development

It doesn’t matter how large or small of an organization you work for, if you are not building security in upfront, you are asking to be hacked.  And, yes, that may mean breaking the current processes you use to manage and build your infrastructure, as well as your software development lifecycle.

Several years ago, Microsoft was the recognized pariah in the security world.  There systems were like Swiss cheese and attacks on the MS-Windows operating system and MS-Applications were a daily occurrence.  Finally, in January, 2002, Bill Gates sent an email to every employee of Microsoft laying out the strategy to develop security within their products.  Bill named it Trustworthy Computing – which over time morphed in to the Microsoft Security Development Lifecycle.  When it comes to developing secure operating systems and applications, Microsoft is now ranked among the best in the industry.  Bill Gates was famous for being able to pivot the Microsoft machine and finding a way to successfully change the direction and trajectory of the company.

So, what are you doing to ensure the security of the systems that you are putting in place?

Tags: SDLC, Software Development, Lifecycle, Process, Application Development, Security, Web Development, Application Security

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

Security: Wrap Up

Just in case you haven’t been reading my past couple of posts – I’ve been discussing security.  Specifically, the need for organizations to take proper steps up-front within their development lifecycles to mitigate the risks of being hacked.

If you still don’t think this is something to be worried about, let me give you some information:

• A Forbes article in 2011 states that the average cost of a private information leak was $6.3 million: Forbes: Data Breach
• When crackers took down Sony in 2011, they reported that it cost them $170M to clean up the mess and put their sites back on-line: The Bright Side of Being Hacked
• As Verizon indicates in their report, many of the organizations hit did not experience direct losses.  They did end up spending money on forensics and recovery losses – how much can your company afford to pay an external forensics team to determine if you’ve lost data or not? Verizon: Data Breach Report

Unfortunately, cracking is not as difficult as you might think.  Here is a link that shows how crackers expose passwords once they’ve stolen the files off your system:

• AirsTechnica: How I Became a Password Cracker

If you really want to scare yourself – go to YouTube or Google and search on ‘How easy is it to hack someones computer’.  

This is the easy stuff – there are dedicated web sites used by professionals where they pass around password lists, sell and purchase stolen data, or give each other access to networks that they’ve cracked.  With a few clicks they can purchase or give away thousands of “identities” – ie: the customer data that they steal from you.  Are you keeping customer’s names, addresses, phone numbers, email addresses?  This is all stuff that the hackers want to get their hands on.  Even more so if your storing credit card information in your systems.  Do you keep bank account information and routing numbers so that you can process electronic checks?  Again, this is something the crackers will be after.

You may believe that your small potatoes and that the bad guys only concentrate on larger companies.  Nothing could be further from the truth.  They are scanning the internet and looking for weaknesses – they don’t care how big or small you are.  If you have a vulnerable system – they want to find it, they want to exploit it and they want to take as much as they can.  You need to build security in from the outset, you need to continually apply the latest security patches to your infrastructure and you need to ensure that your development teams – internal as well as external – are using industry best practices to mitigate security risks.

So, if my previous articles didn’t make you think seriously about incorporating security best practices within your organizations and the systems you develop, hopefully this article has helped tip the scales.  You need to review all of your systems, those built in-house and those purchased off the shelf or custom developed for your organization and you need to ensure that they provide the necessary security protections.

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #security, #webdevelopment, #applicationsecurity

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

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