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

Out of the Darkness comes Light …

I really liked one of the first professional programming jobs that I ever had.  The people were great, I learned a lot on a daily basis, we had fun at work and after we left work.  I made great friends.  We had good clients – sometimes they were demanding, but nothing too unreasonable.  The company was stable and seemed to have a bright future.  While I did put in extra hours, it wasn’t required and I got recognized for the effort.  They let me play with new technology and I got to interact with development teams at some of the significant players in the industry, at least they were at that point in time.  So, the question is, why did I leave?

Although I really liked the people, the technology, the product we built and the customers – there was one thing that overshadowed everything else … the person who ran the company.  We’ll call her Edna.

Edna was great at sales – she could walk in to a room and convince anyone and everyone that she had the cure for cancer, if they’d just sign on the dotted line.  The issue – Edna had no clue how to interact with her team in the office, she did not understand what it meant to develop software and didn’t want to take any time to at least understand what it was that her team did.  This company lived off of the software that was built by an incredibly talented group of individuals.  And I’m not just talking the developers – top to bottom, the company had some incredibly talented people: business analysts, customer support, finance, marketing and development.

Edna consistently put a strain on this team because she had no idea how long it took to actually develop new functionality.  She would get in front of the customer, who would request some unique feature, and then put promised delivery dates in the contract.  Edna didn’t take the time upfront to discuss the “concept” with the team, so we were always under the gun to create the latest “whiz bang” that had been promised our latest customer.

Now, before you fire back, yes, I realize that when the product that is being marketed is a software package – that during the sales process, there are most likely going to be customizations that are requested.  And, I actually do understand that it is the development teams’ responsibility to deliver those customizations.

My problem was that we had no time to plan.  We were constantly shifting from one emergency to the next, as we scrambled to accommodate the latest promise.
To top this off, Edna’s style of management consisted of pulling people in to a room to have a meeting, and then berating them because they weren’t moving fast enough.  Really?  So I got the specs last week.  Oh, and by the way, the specs are woefully incomplete and now you’re not satisfied that I’m not making enough progress.

One day I went in to work and was immediately pulled in to a “meeting”.  There were six to eight of us in the room with Edna, and the meeting lasted the entire day.  Not one person was left unscathed during the 8 hour marathon session.  Edna had made promises, and by God we were going to work to make sure that the necessary functionality was complete by the date she had put in the contract.  While I was just a developer at that point, I clearly remember the senior manager in charge of all the development teams attempting to shield the rest of us.  It didn’t work – she blasted him with everything she had, in front of all of us, and then methodically worked her way through the room.  She had no respect for the people in that room – not her managers and clearly not the team members.

I left the building feeling miserable.  I didn’t know what else I could do – we had all been working hard on this latest project and were making excellent progress.  Yet nothing we were doing seemed to make Edna happy.

I got home, and it couldn’t have been more than 30 minutes when the phone rang.  I remember looking at my wife, telling her it was probably Edna, and to let Edna know that I hadn’t gotten home yet.  My wife answered the call and then told me that I needed to take the call.  The call ended up being the human resources contact for a company that I had interviewed with 6 months prior – the position had been on hold, but was open again and she wanted to know if I’d take the job.  I didn’t have to think for more than 2 seconds before I answered with a big “YES”!

As I left that job and moved on, I made a promise to myself.  That if I ever became a manager, I would never treat people the way that I’d seen Edna treat her team.  I really did like the team that I worked with – I think about those days every once in a while, at least the ones where Edna wasn’t in the office.

I’m not sure that I understand the mentality of management by fear.  I do recognize it when I see it, it’s not pretty and it’s very destructive to those that have to work within its grip.

I’m not saying that people can’t have passionate discussions.  That’s only fair – I think some of the most incredible leaders I’ve met know how to encourage these types of discussions.  It really does allow teams to break through tough problems.  The difference is leaders that know how to do this properly, know how to manage the flow of the “discussion” so that it doesn’t become personal.  They also know how to get people to listen what is being said, so that teams can understand what is possible.

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #leadership, #management

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

As Leaders we need to Support our Teams...

So, here it is very early on a Sunday morning – I mean really early, 2:00AM to be exact.  And, I’m in the office.  I don’t really need to be here.  If you want to get down to the nuts and bolts, I’m not actually here to do anything!  The team is implementing some changes to one of our key applications tonight.  The best time to do this is in the middle of the night when transaction volume drops significantly.  So if I’m not here to do anything, why am I here?

In the building tonight is everyone from the project manager, developers, architects, database architects, to infrastructure team members.  They have the implementation plan documented forwards and backwards – in fact, most of the implementation plan has been executed in the last week as we’ve moved chunks of code in to the production environment.  Not only have they documented the implementation, but they’ve practiced the implementation and rollback steps in our parallel environment.  Making sure that each step has been identified and that we know how long each step should theoretically take.

These are good people – that take their roles in the organization seriously and who are passionate about making sure that we provide the best service possible across our network.  Not just good people, great people!

So, again, why am I here?  The people running the implementation tonight are competent and can handle any situation that comes up.  They don’t need me looking over their shoulder asking questions – in fact if I did, all that would do would be to slow things down.

There are really two reasons that I’m on site:

• My being here shows the team that I care and that I’m not putting myself above them.  If I’m asking them to come in during the middle of the night – then I should be willing to walk in that door with them.
• I’m here to act as a communication point if something does go wrong.  The last thing that I want the team to worry about if the stuff hits the fan is to call me to tell me there is a problem.  It’s actually my job to be here and if there is a problem clear any roadblocks, take responsibility to inform my boss, our CIO, and potentially the rest of the Senior Management Team.

Yes, I live just minutes from the office and can easily be on-site within 15 minutes.  It would be easy for me to stay at home and head to bed instead of staying up all night.  But does that show the team that I’m willing to be a part of the team?  No!

My small effort to support the team has been noticed and is appreciated.  I’ve had development team members, as well as people that don’t report up through the parts of the organization that I manage stop me as I roam the building and thank me for coming in.  They feel better knowing that I’m there, that I’m willing to help and that I’m willing to try and take some of the burden off their shoulders if push comes to shove and something goes wrong.

The good thing is that I rarely have to engage during these implementations.  Because I trust the team to do their jobs and because I know that they care.  I’m here in a support role and that’s ok!

How do you show your team members that you are part of the team and that your willing to step in and support them?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #leaders, #leadership

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

Testing is NOT an Afterthought …

Many years ago, I had been hired as a programmer for a small firm.  My first assignment was to take the accounting package that the firm was already selling and modify the package to work for manufactures.  I literally was given this assignment my first day on the job.  There was a deadline on getting this done and I was actually given a PC to take to my apartment and do the work – and no, there was no such thing as an internet to connect back in to the office.

I worked round the clock – not being married at the time, and new in town, it really didn’t bother me.  I would go in to the office a couple of afternoons each week to work with the test team and to show my manager the progress that was being made.  At the time, I remember thinking – “why are these guys picking on me?”  They would take issue with small things that I was sure wouldn’t make a difference – yes, they also found other items that were bigger and I knew I needed to address, but I couldn’t figure out why they were so bothered by little issues on the screens or reports.  This went on for a couple of months until I finished the new package and was then asked to go out and install it for the customer.  All the while I pushed back on all the small changes that the QA team was asking me to make.  In my mind – they were just slowing me down.  It was only when I was on-site with the customer that I finally realized that the QA team wasn’t picking on me.  The customer was elated with the end product – in fact the owner of the company pulled me in at the end of the week to tell me how pleased he was with what had been delivered.  His comments about how much this was going to simplify his people’s lives and how impressed he was with the accuracy of the information being displayed and reported on – what a change it was going to make for his business.  That’s when I realized that the QA Team wasn’t picking on me, they were advocating for the client.

I work in an organization where thousands of transactions can be hitting our switch in any given second.  These are all financial transactions – payments, transfers, deposits, etc.  When you’re out on the road in the middle of the night and hit a gas station to fill up – you want your card to be recognized and the transaction approved.  When you’re out with a group of friends and paying for dinner – you want your card to be recognized and the transaction approved.  When you’re on vacation and paying to get your family in to a hotel – you want your card to be recognized and the transaction approved.  You don’t want to hear the words – hey the network is down and we couldn’t process your payment.

Our systems must work 24 hours a day, 7 days a week, 365 days a year (24x7x365).  Not only must we make sure that each and every transaction coming through our switch gets routed properly for the authorization decision, we must track every transaction on the network and then settle with thousands of financial institutions, merchants and the Fed every night.  That means we must balance down to the penny across all of the cardholders, merchants, financial institutions and ultimately with the Fed every day to actually make the money move between the various accounts.

We can do this because we have great people that are passionate about what it is they do and because we have built processes that allow us to validate our systems before they move in to production.  Quality is not an afterthought!

While we have done a good job with quality – I’m now looking at how we can do this more efficiently within our organization.  To date, we’ve been successful because we are able to take advantage of the wealth of knowledge that we have within our teams.  People who are very passionate about getting it right!

Doing this right means planning it right.  Very early in our processes we must begin to identify how it is we are going to validate what it is we are building.  This isn’t a matter of testing a web page – or as one of our Enterprise Architects would put it, “the fluff”.  This is digging in and validating real-time interfaces between point of sale devices, automated teller machines, our switch, other networks and processors and ultimately our backend billing and reporting systems.  Some of the systems we don’t control.  The systems all pass data among each other through documented interfaces without human interaction.  It all transpires in milliseconds, and must work every time – all the time!

When we are building a system – it can cross multiple silo’d application environments, yet the card holder views it as a transaction.  Our tests must take in to account every part of the transaction – at the terminal are we displaying the correct screens to the cardholder, are we displaying and reacting to all of the buttons properly.  Once the transaction is initiated, we must make sure that the various data elements are represented properly within the messages that move between the terminal and our switch.  Once the transaction hits our switch we must ensure that the data elements are reformatted properly to send to the authorization agent – sometimes that’s us, sometimes that’s other processors off our network.  Then we need to make sure that the data flows to our backend billing systems, reporting and maintenance systems.

This gets very complex, very fast!  So how do we do it?  Have I mentioned our people – they are very good at what they do!  The first thing we do is we plan.  Our QA Analysts, Tech Leads, Subject Matter Experts and Engineers all work together to develop not only the individual unit testing that will be needed on any given application being touched, but more importantly, they plan on how to test all of the integration points between the systems.  This means this group of people breaks down the transaction flow across all of the systems – starting with when the card is swiped to the point where the cardholder sees that the transaction has been approved.  We need to plan to ensure that the test card data is setup properly across all the systems – that means the underlying test data associated with the dummy financial institution that issued the dummy card.  We have to setup test environments representing all of the pieces of the network and touching all of the sub-systems or silo’d applications that the transaction touches.  The integration testing is key to ensuring that we can take those transactions from the point of initiation all the way back to the user seeing the transaction approved, the financial institution getting the proper transaction reporting and settlement, the Fed getting the proper settlement information and the user ultimately being able to see the transaction in their on-line/mobile banking applications and on their monthly statements.

But you can’t just stop at the planning – you have to monitor the execution of the integration test plan.  Are all of the identified tests being executed?  Are you getting the expected results?  What happens if you insert an invalid value in to one of the data elements being passed around the various systems?   Can you prove that the settlement reports are accurate – to the penny?

As a developer, I’ve made my fair share of mistakes.  It always irritates me when I, or someone else, finds an error.  But what irritates me even more is when one of those errors makes its way in to the production environment.

Computers are excellent tools – however, if we don’t take the time to validate the information that we are presenting to our end users, we can lead them to make huge mistakes.  Just think if I made a small mistake on every transaction moving through our switch – that’s millions of transactions every day.  Do you think the cardholders would be happy if I randomly, and without reason, declined their transactions?  Do you think the financial institutions would be happy if I couldn’t tell them which cardholders to debit or credit and how much money needed to move between accounts?  Do you think the Fed would let us stay in business if we couldn’t balance our transactions and give them invalid information on what money needed to move between financial institutions and merchants?

What are you doing to improve the QA processes on the programs you’re creating, the team you’re working on and the organization you represent?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #qa, #qualityassurance

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