A Simple and Practical Approach to Security

Security on the Brain
In his guest blog post below, Neil McIsaac talks about the importance of thoroughly understanding and implementing security requirements to keep applications safe. Of course, that’s something that we all know, but is it something that we always do? Most likely, not always. That’s partially because security is complex and takes time to implement. Many of you, these days, don’t have that time (it’s all about shortest time-to-market, right?) to think about security. You make sure that minimal security checks and balances are there, but that’s about it. Totally understand.

But security doesn’t have to be complex to implement once you know what you have already available to you in the frameworks and products that you use every day. Over the course of the next few weeks, check back often as we’ll be demystifying application security, covering things like social engineering, secure code review techniques, simple things you can do to protect your applications, how to use the tools and frameworks you’re already using as your lines of defense against hacking, and more.

Feel free to start or join discussions in the Canadian Developer Connection LinkedIn group to give and receive thoughts and feedback on these or any other topics from fellow Canadian developers and experts.

Guest post by Neil McIsaac. Bio below.

We all know of the importance of security and the unfortunate result of a breach. Too many organizations realize this after it is too late when their name is seen across the news channels has having lost their data to a hacker or even worse, from negligence. What about those that never make the headlines? The hackers that go undetected? So are you handling security effectively?

The challenge is that security is a question of balance and knowledge. We need to balance the correct measure of security with the asset that we are protecting. The most secure room is one that nobody can enter, but is that useful? When it comes to knowledge, we need to know not only how to properly implement effective security measures, but to also know what kind of threats we are protecting ourselves against. Keeping current on technologies and security best practices is a never ending quest that organizations must endure if they wish to protect their assets. Surprisingly, most organizations fail at the fundamentals, and not at the level that would be worthy of someone from the movie “Hackers”.

Lastly before jumping into the guidance, I feel I need to repeat something that everyone has heard – Security is everyone’s business. Quite often good security practices are left between the cracks of the blame game, where developers say that “Security is the IT admin’s job” and the IT admins say that “The software should already be secure without the need for me to configure a bunch of stuff”. The advice I have below may sound like it is administrator focused, but it is not. It applies to everyone, including the developer. Matter of fact, I think the developers need the advice below even more than the administrators since the systems that are built by developers need to not only follow the advice below during the building of the software, but also facilitate an administrator in performing any of the advice below as well.

A simple approach – There are 3 big pieces of advice I give my clients when discussing security best practices. They are:

1. Answer the 3 basic questions
2. Always follow the asset
3. Keep current

Organizations that follow this guidance in one form or another tend to have successful security practices. Let me describe them, and I think you will see how simple they really are.

Answer the 3 basic questions – you need to always be able to answer these simple questions when it comes to security. Unfortunately, as you go down the list, you’ll notice how we typically get worse and worse in answering the questions. The three questions are:

• What are the security requirements? – At a high level, who should have access to what? This is a question that is typically well answered by most organizations. For that reason, I won’t waste your time delving into it.
• How do we know we meet them? – Simple put, every security plan needs to show that we actually meet the requirements that were outlined, so the question becomes how do we audit security? Auditing can range from simple user testing to in-depth security testing such as penetration testing. For the system implementers out there, this means that we need to ensure that we can successful audit our system. For the developers out there, it gets a bit more complex. Not only do we need to ensure that the administrators that are using our software can audit simple things like basic user security, but we need to also ensure that the code that we write can endure a variety of lower level hacking style attacks. The question remains the same though. If the requirement is that the code that I write is secure against hacking attempts, how do I know it is secure? Proper software testing is the key to that. Hopefully when I get a bit more time, I will follow that up with my other favourite rants on security on the importance of software testing, but for now the point is, you need to be able to answer YES to this question and be able to prove it.

The final question is the one that I think as an industry, we are the worst at.

• When is the last time we checked? – We need to make auditing routine. If something changes, is it compliant with our security requirements? Quite often we see changes to systems to troubleshoot a problem or other reasons, elevate security in some form and it goes unnoticed and possibly unchanged. Having the ability to be notified or even block a process that is not security compliant is ideal. For software developers, that typically means that we need to incorporate those features into our software design. Does your software have an auditing feature? Has it undergone proper security testing? And by ‘proper’, I don’t mean relying on user testing.

Those 3 questions will help you solidify a basic approach to security. To help handling security at wider scale, such as throughout an organization, I present the second best practice.

Always follow the asset.

The asset in your organization is what you are trying to protect. For arguments sake, let’s start off with something like a credit card number. Most organizations would point to where it is stored, and say “Look! It’s encrypted where we store it!” However, if you trace the asset through its lifetime, you’ll often see other places where the credit card number exists where it is no longer encrypted. For example, when the person entered the credit card number into the screen, was it encrypted during the submission? Was it encrypted during transport between the client and the database? Is there other software, such as a payment application that reads the credit card number from the database and submits it for authorization? How secure is that? Quite often we secure an asset by securing its container. It is only when we follow the asset throughout its lifetime that we can better apply the appropriate security to all of the places where the asset can live, whether it be its storage container, or during its transmission between systems. When you follow the asset, you can ask the question “Is it secure here? What about here? Or here?” and readily identify the other places where an asset which needs to be secure, lives.

Another example that probably hits a little more closer to home, consider the way that document security is typically handled, as a file in a folder. Most organizations secure the folder, audit it, test it, and give themselves a giant pat on the back when they say “Yes, we’ve secured the document”. As a manager that has permissions to read the document, where does the document exist when I open it? Could I attach it to an email and send it to someone? What about copy it to a USB key to take home to work on there? How secure is the document now? Was the security on the folder effective? I think not. Security with this approach has ignored the fact that data “lives” in an organization. It moves, it breeds (gets copied if you’re not sure where I was going with that!), and an organization needs to “follow” this asset where ever it may live. Once you have an understanding of where it can live, then you can better apply the appropriate security.

Lastly, the final best practice and I think the most obvious – Keep current.

I think it goes without saying why this is important, so my point is this, and I’ll start with a quote by Peter Drucker, “Plans are only good intentions unless they immediately degenerate into hard work. ” The common issue with keeping current is that we have to take the time to stay current and that time usually gets pushed aside for what we think are more important things. So the goal here is to ensure that an organization makes keeping current on security best practices part of its common practice. Perhaps by scheduling a monthly or weekly meeting where the focus is to share and discuss topics concerning security? Or maybe to attend a security conference or course? The goal here is to always extend the organizations knowledge with respect to security and never let it fall by the wayside.

I hope that this simple guidance will help you find a secure solution, and help avoid landing you on the front page of a newspaper!

Neil McIsaac

Neil McIsaac (MCPD, MCITP, MCTS, MCSD, MCDBA, MCSE, MCSA, MCT) is an accomplished educator, consultant, and developer who specializes in enterprise application development and integration, application architecture, and business intelligence. As an instructor, Neil shares his knowledge and years of experience with students on a wide range of topics including SharePoint, BizTalk, SQL, .NET development, and PowerShell.

Neil is an owner of BlueGreen Information Technologies Inc., and has over 18 years experience working in the IT industry in both the private and public sectors. His focus on large scale application development and integration keeps Neil involved almost exclusively with enterprise level companies. However, he also works in every level of government.

Neil lives in Moncton, New Brunswick, Canada. In his spare time, Neil enjoys downhill skiing, golf and a new motorcycle.

Photo credit: railking