Security for Web Developers

It seems like every couple of weeks, there’s news that another major site has been compromised.  And yet, often when I read the details of how the bad guys got in, it seems like the breach should have been easily avoided.  So here are a few of the obvious steps that web application developers should consider.

SQL Injection.  This one is as old as the hills.  Most database implementations allow SQL commands to be embedded within each other.  Bad guys take advantage of this by embedding a command within a field on a form, a command like return all the passwords or credit card numbers.  Some programming languages/environments automatically check for SQL injection.  If yours doesn’t, add your own to your application layer.

Password Protection.  Passwords are special.  Design your password features and your database to make it harder for them to be stolen.  From a feature perspective, it’s more secure to allow passwords to be reset than to allow a user to retrieve his or her password.  At the database level, use a dedicated table or even a whole separate database instance for just the passwords, and with your database administrator design how to lock it down tight.  Don’t store the passwords in cleartext.  Encrypt or encipher them with the strongest algorithm and keys you can afford (computationally).  In fact, my preference is for one way “encryption,” meaning passwords can’t be decrypted.  Make your users use strong passwords.

Credit Card Numbers.  See above – credit card numbers should not be stored in cleartext.  Encrypt them.  In addition, never show the entire credit card number back to the user in case his or her account has been compromised or someone is peeking over his or her shoulder.

Architecture.  Before you even start coding, discuss your architecture with the network administrator.  You’ve likely heard of 3-tier architectures, or N-tier architectures.  One of the reasons a 3-tier architecture is popular is that it neatly accommodates the role of a modern firewall, with it’s DMZ and private zone.  It can be hard to change the architecture later, so understand how to make it possible for your network administrator to deploy your application in a secure data center (virtual or otherwise).

Application Access.  Don’t be lazy and just assume your application will have superuser access.  Setup a user for the application to run as.  Setup a database login that the application will use for the database.  Neither should be superuser.  Might I even suggest grouping your applications by the kind of access they require, and defining different logins for each application?  Yes, it will take more time – you’ll have to define groups for all the other users that need to access the same data.

Encrypt Connections.  Use HTTPS instead of HTTP.  Use Secure Socket Layer for non-HTTP connections.  This applies not just for browser to web server connections, but server to server connections in your data center.

Stack Overruns.  This isn’t as relevant nowadays, but if you use one of the older compiler languages, arrays are vulnerable to a hack by overrunning the stack.  Check and/or truncate the length of every user input against the array you store it in.  Or use heap memory instead of stack memory.

Well, those are some of the basic measures to take.  Thought of something else I overlooked?  I’d love to hear it.

Security is always balanced against implementation effort and ease of use.  And of course, there are always competing priorities.  But think of the impact if your site makes one of those headlines.  Customers won’t trust you.  Heck, business partners won’t trust you.  Application security doesn’t increase revenues, but if your site is compromised, that sure will.

Positive Inquiry and Software Development

I recently attended Tenny Poole‘s workshop on Positive Inquiry – Cultivating the Art of Appreciative Leadership.  Positive Inquiry (or Appreciative Leadership) is a leadership philosophy of engaging with employees with a positive orientation in the belief that such a philosophy yields greater results.  I have long thought and tried to practice looking at the positive side of any problem in my own management style.  But when the workshop began, I realized I was almost the only non-HR executive in the room.  Certainly, I was the only technologist present and I must confess that we software engineers are a cynical lot.  I mean, isn’t Appreciative Leadership just a bunch of HR cheerleading, even psychobabble?

Tenny quickly put those thoughts to rest with some facts.  She cited a Gallup study in lost productivity, university psychology studies, and more, all to build a fact based case that disengaged employees are costing companies money.  And you’ve all seen it in your personal careers – that employee who is just going through the motions, or worse, actively fighting or undermining the company’s initiatives.  Haven’t you ever wished, if we could just get everyone on board and in gear, we could get so much more done?  Well, Appreciative Leadership is one way to improve that employee engagement.

I’ve already touched on how this relates to software development with my mention of cynicism in the ranks of software engineers.  But what really connected Appreciative Leadership to to real world for me was when I finally finished reading Agile Software Development with Scrum by Schwaber and Beedle.  This book was first mentioned to me as the definitive text on Scrum, likely the most common software development methodology in practice today.  Early on, the authors state that the first four chapters are the most important when it comes to implementing Scrum, as they cover the mechanics of how to practice Scrum.  The last five chapters are more about why it works.  Being the ever busy manager, I originally took that as my cue to read just the first four chapters, so I only recently completed the book.

When I did, I was surprised to find that the kind of organizations and the behaviors that Scrum creates are very much the kind of things that Appreciative Leadership seeks to create.  This was really driven home in chapter 9, Scrum Values, as it talks about values that are the same values advocated in Positive Inquiry.  So it’s my contention that Appreciative Leadership is a natural fit for managing software development teams.

In her slide on Appreciative Leadership behaviors, Tenny talks about listening to others, valuing what they are trying to communicate, and honoring diverse viewpoints.  Schwaber and Beedle devote sections in chapter nine to Openness (9.3) and Respect (9.4), and throughout the text speak about how Scrum encourages that same kind of transparent communications and a culture of mutual respect.  Tenny talks about a healthy culture where it’s okay to not know the answer, and moving past the blame game.  Scrum likewise allows a team member to solve a problem with what resources are available, where any team member is free to meet his or her commitment with whatever solution is necessary, including asking others for help.  I’ve certainly seen some of my teams support each other in that fashion.

The similarities are far too numerous to detail here.  Let me cite one last one – Scrum ultimately works because every team member commits to the sprint, and in the daily stand-up meeting, to achieving certain goals.  That commitment is the quintessential demonstration of employee engagement that Appreciative Leadership seeks to strengthen.

So while I’m a new student of Positive Inquiry, I can’t help but think I’ve been practicing it for years.  I picked up a couple of books for the class, and I hope they’ll reinforce how I can be a better leader for the software engineering teams I lead in the future.

 

Easing into Scrum

Recently, a couple of different people have asked me about my experiences adopting Scrum.  Scrum is, as many of us in the software industry already know, a software methodology that has become very popular.  Still, there are some places that haven’t yet converted from one of the old methodologies.  One of, if not the, definitive texts on Scrum is “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle.  The coincidence that occurred that gave me the idea for this blog is that different people who don’t know each other asked me if and how to get their organizations into using Scrum.  Hopefully, this column will give people such as they the confidence to ease their organizations into Scrum.

Now there are plenty of blogs out there about Scrum.  If you want to read about Scrum in general, well, Google is your friend. My somewhat unique point of view is that I recently led a number of development teams which had implemented Scrum with varying degrees of fidelity.  From that, I learned firsthand that Scrum is very flexible.  You can take or leave bits and pieces of the methodology.  To be sure, there are some parts that are pretty critical, but even Schwaber and Beedle talk about it being flexible, and that every organization needs to adapt Scrum to their organization.

At one end of the spectrum, I had 1 and 2 person development teams with absolutely no process at all.  Requirements were communicated verbally or by email, weren’t documented or organized anywhere.  Releases happened whenever the code was ready (and were still considered late).  At the other end of the range, my largest development team was our most mature product,  producing significant amounts of company revenue.  Every requirement had to be documented in a user story that was maintained in a backlog.  Daily stand-up meetings happened like clockwork., and every 3 weeks, so did a release.

Pretty early on, I decided it would be best to make Scrum a department wide standard.  Team by team, I worked on adopting Scrum.  First, I generally began scheduling a daily stand-up meeting.  Hopefully, the product owner attended, but that sometimes took some coaxing.  While not ideal because the manager shouldn’t be the Scrummaster, I acted as Scrummaster.  We talked about what we accomplished since the last stand-up, and what we would finish by the next stand-up.  If there were any roadblocks, those were to be discussed as well.  I tried to follow the cardinal rule that team members needed to commit to their fellow team members, though I confess I would push for some goals.  Frequently, we would veer of into the weeds about specific technical problems.  I’m probably guilty of violating that Scrum rule more than most.

Next I started asking for user stories, organized into the current sprint and a backlog.  Often, the user story was a simple one liner entered by the developer or myself.  But it serves as a placeholder.  With that, we could understand what features would be in the next release.  Although often vague, we could take a stab at assigning a level of effort, or story points, that could be used to at least sanity check how much work we had to complete in the current sprint.  Bugs (defects) could also be tracked – they merely became new user stories in the backlog.  And, of course, organizing stories into sprints implies our next Scrum element – releases are the culmination of each sprint.

With those two (three?) elements, I was satisfied we were practicing at least the basics of Scrum.  Engineers felt there was at least some organization to the process, instead of the unruly chaos that had preceded.  The business felt we were keeping track of requests (mostly), and had a better feel of what would go into each release.  Never did I hear anyone asking “What’s going to be in this release?”

My typical ongoing challenge was getting the product owner to participate more in the Scrum process – coming to the stand-ups and writing down requirements as a user story.  We were never in danger of over documenting requirements, which is what we wanted.  As we coded something, we wanted the flexibility to go back to the product owner and propose a change.  And we certainly didn’t want to spend time specing out every last pixel beforehand.  Still, on almost every project, I felt as if we needed more participation from the product owner.

Usually, we would eventually also add a sprint planning meeting at the start of every sprint.  A couple also added sprint review meetings (post-mortems).  Only one team added built-in automated testing, which is an Agile idea, but not actually part of Scrum.

I rolled this out across multiple development teams.   Each had their own variation – no two were identical in how their Scrum process evolved.  There was still a whole range of practices, each fitting the unique requirements of the personalities and styles of each team.  Even my large and most Scrum proficient team, we were always tweaking the process, improving it for what we needed.

And that’s all it took.  It wasn’t a great policy announcement, or other grandiose effort.  It was all very much organic.  We just started doing Scrum, piece by piece, team by team.  If you’d like your team to adopt Scrum, I think you’ll find it really all comes pretty naturally.