We often talk about how hard security is to implement. But in all truthfulness, security isn’t that
hard to implement. We know how to
protect against vulnerabilities. We have
the OWASP Top Ten which we can recite in our sleep. There’s a security conference somewhere in
world every week. There’s thousands of
YouTube videos of security-related talks and demonstrations. How do you protect against SQL
injection? Use query
parameterization. How do you protect
against XSS? Input validation and contextual
output encoding. I have plenty of
conversations with developers on a daily basis.
When I explain what the vulnerability is why it’s a risk they understand
almost immediately and know exactly how to fix it. It’s just that security is often
misunderstood by a lot of people involved, whether it’s the business side,
developers or even security professionals.
My company was fortunate to host Jim Manico for a day of
developer training, which wasn’t long enough but we made it work anyways. We had great turnout from the development
team and there was a lot of good discussion throughout the day. Weeks after the training, I continued to
receive messages from developers who attended the training asking me questions
and telling me how they reviewed important components of their code and were
able to make the code more secure. The
developers know how to write secure code!
They just don’t understand when or even why the security is needed. Knowing when to implement security and how
much security to add in is more of an art than a science. There are many factors that influence this
including performance, accessibility and ease of use.
From a security side of things, we often confuse
priorities. Far too often we run around
screaming the sky is falling when we find a XSS vulnerability on the home
page. Sure, the vulnerability needs to
be fixed but it will go into the bucket of items with all of the other
priorities. A major feature that is
going to propel the company to the head of the pack will take priority over a
seemingly innocuous XSS vulnerability.
The developers will fix it in due time. But for the time being it is the security team’s
responsibility to work with the business to make sure the new feature is
delivered on time and bug free. Many of
you have probably seen the following picture and cringed when you saw security
at #7.
This is really great news!
Security made the top 10! That
means it has visibility. Whether it
ranks #1 or #10 doesn’t matter. The
point is security is getting the attention it deserves. Without the other priorities on the list,
security doesn’t matter and no security professional will have a job. This list does not imply that the Cloud is
going to be built without buy-in from security.
Far from it. Security should be
baked in from the very beginning. And
because security is on this list I believe CIOs understand that.
Let’s take a step back, take a deep breath, and relax. Security isn’t hard, it’s misunderstood. I have been guilty of wanting to place
security requirements above functionality without taking into consideration how
the requirement will impact the system as a whole. Not to mention some of the security requirements
require a change to the architecture which is not an overnight fix. Anyone who has developed software knows what
it’s like when someone comes to you and adds an additional requirement to your
software that you did not account for in your design. After lots of cursing, it’s back to the
drawing board and trying to figure out how to incorporate the new requirement
into the design with minimal impact. But
the fun part of being a developer is being able to come up with creative
solutions to complex problems (or so that’s what I tell the developers I work
with). At the end of the day the
business, developers and security professionals are all one team. It is our job to work together to build the
best product possible which includes building in the best security and
delivering an experience to the end user that is unmatched.
