Categories Performance Monitoring

Expecting and getting both performance AND security

When implementing new applications in their organization, IT departments are typically more concerned with security than performance, however they will find that upper management and, especially, the end-users won’t share this concern and give performance higher priority. This situation is the basis of the article, “Security vs. performance,” written by John Leonard and published in Computing magazine.

The article discusses making trade-offs between the security and performance of applications — what organizations can do and where they can draw the line. It presents an interesting dichotomy, but I believe no dichotomy actually exists. The article implies that security is predicated on the idea that you know about and can control all the applications that are at risk and specifically all the data they contain, but that’s not really the case. The average Fortune 2000 company runs 461 SaaS applications. With so many applications, IT isn’t going to know about each and every one of them, which means they certainly can’t control the data they contain. However, the real reason they can’t control the data is because end-users’ need for ease-of-use always trumps IT department’s best practices. IT can push its security rules and procedures all it wants, but if users can go around them, they will in order to make their jobs easier.

Users Come First

One example of this comes from the recent hacker attack at Sony, where hackers got 100s of thousands social security numbers and bank account information, even from people outside the company. One discovery that was particularly embarrassing is that there were numerous passwords to Sony corporate accounts in a folder that was simply labeled … “passwords.” Horrifying, until I think about how many times I’ve shared our Twitter password over email. Or used a single login to get around a product’s user limits during a trial. People will do that sort of thing because it’s easy and they need to do their job first and think about security second.

You Can’t Control What You Can’t See

Security is, first and foremost, understanding what’s out there and what you are able to do. You need to be able to understand what applications are in use in your company — that your marketing department is using a tool that’s storing data, and that sales is storing data in spreadsheets or copying sensitive information onto a shared server in a folder called “passwords.” You simply need to understand the behavior of people in your organization because they use the applications. Secondly, you need to keep your information up-to-date. Contracts renew, people switch products, data moves around, people get fired, and people get hired and bring in their favorite applications. With your applications and data changing all the time, keeping a consistently accurate picture of it is incredibly important. I’m not just talking about assessment; I’m talking about monitoring as well.

A Crash is More than a Crash

The reality is that there is no dichotomy of security and performance — they are actually one and the same. Availability and performance are closely related to security. If feeding the login page garbage data can crash a SaaS app, it’s a good indication that there’s insufficient validation on that page. Crashing could be the best-case scenario; the right string of garbage data could return a root shell. While crashing bugs are first treated like an application performance and availability issue, the people who deploy and use these applications also consider them security issues.

What to do?

It’s important that

  • The applications that end-users are going to use (regardless of their security) are monitored,
  • Expectations are for both performance and security, and
  • Everyone is mainly focused on making sure those applications work so the company can maintain productivity and conduct business.

It’s much more about getting everyone on the same page and enabling people, as opposed to making trade-offs between security and performance without involving the whole organization.

TR Jordan: A veteran of MIT’s Lincoln Labs, TR is a reformed physicist and full-stack hacker – for some limited definition of full stack. TR still harbors a not-so-secret love for Matlab-esque graphs and half-baked statistics, as well as elegant and highly-performant code.