This article is part of an ongoing series. See the blog entry Delivering Your Enterprise: The ilities for an overall discussion.

Ah, Security. It’s one of those things most of us don’t think about until there’s a catastrophic failure. It’s a fundamental part of our enterprise high wire act. And when the wire on your trapeze breaks, it doesn’t do much good to check if there’s a safety net below you. You’ve either planned ahead, or you have to accept the consequences of failing to plan.

Before we get into more details, let’s discuss what really drives Security: cost versus benefit. If we (you, your management, your customers) don’t see benefit in making a system secure, we just won’t pay the cost (in terms of dollars, time, effort, customer relations, etc.). If only five people use your system, maybe spending $100,000 for security isn’t worth it. On the other hand, if that system contains nuclear missile launch codes, spending many times that amount would be worth it. It’s not a simple equation.

Furthermore, evaluating the tradeoffs between the costs and benefits involves a certain amount of gambling. In the example above, your first inclination may have been to assign a low value to security of the system, since there are only five users. When I increased the value of the assets being protected, hopefully you changed your initial assessment. The point is that we rarely, if ever, fully understand all the costs and benefits in our security tradeoffs. Since we can’t plan for every eventuality (like the recent Heartbleed bug), we have to gamble conservatively but expect surprises.

So what are we really talking about when we say Security? There are lots of things to consider when you try to keep your enterprise secure. (Although BYOD is an important part of delivering your enterprise, we’ll concentrate this discussion on enterprise servers and not so much on PC’s and mobile devices.)

  • Authentication – How are users identified to the system? Email address, retinal scan, fingerprint? Are other identify factors beyond a password, such as a PIN or security token, involved? Can this identification be used across multiple enterprise applications (Single Sign On – SSO)? Across companies (identity federation)? If you centralize user identity storage (like with LDAP or Active Directory), is that system itself secure?
  • Authorization – Who can view this piece of content? Can this user edit documents in general, or this one in particular? What web pages and applications are visible to this user? Is this user able to change all or part of the layout of the web page? Who can create or delete user accounts? Can they change the authorization of other users?
  • Intrusion prevention – Did your developers protect against XSS (Cross-site Scripting) or similar attacks? Are web services exposed to the Internet even if internal systems are the only ones that need those services? Do your SOAP or REST web services require authentication or use SSL? Are uploaded files virus checked?
  • Infrastructure – If intruders get past your exterior firewall, do they now have free access to all your systems, or do you have multiple layers of security protecting your enterprise assets? Do you use multiple subnets to segregate application, database, development, and production servers? Will your database servers only accept connections from known application servers? Are your systems physically protected with locks and access control? Do your data backups actually work? Are backups stored in a separate, secured location?
  • Encryption – Do you use SSL for any web site dealing with sensitive information? If intruders get past all your security measures to your data (after all, any real or virtual lock can be defeated with sufficient determination), can they simply read passwords, identification numbers, and other critical information? Or are critical data encrypted as another layer of protection?
  • Policies and procedures – How long after an employee departs is their authentication and authorization revoked? Does published company policy warn employees of the penalties for abusing electronic systems? Are your password policies so Byzantine that people can’t remember their passwords, and so leave them on yellow sticky notes next to their computer? (Best intentions defeated by human nature – I’ve run into this more than once.)
  • Other considerations – Will you know immediately (or days later?) if an intruder makes it past your defenses (intrusion detection)? At a minimum, do you have an audit trail of critical changes made to your systems? How do you protect yourself against unhappy employees or a fan of WikiLeaks?

Sure, there are a lot of questions here. The bad news is that we’ve barely scratched the surface, and you and your team need to ask a lot more questions on an ongoing basis. You are, after all, trying to protect the critical assets of your organization over time. If things are quiet, be nervous; your next intruder may have spent last night learning new techniques and technology that can easily defeat your best defenses.

Speaking of technology, there are a lot of open source and commercial systems that can help you out. For instance, just for authentication and authorization, here are some of the packages (in no particular order) we have worked with to help you deliver your enterprise.

  • SiteMinder
  • Tivoli
  • LDAP
  • Active Directory
  • CAS
  • SAML
  • NTLM
  • OpenId
  • OpenSSO/ Sun Identity Manager
  • Facebook
  • Twitter
  • LinkedIn
  • Novell Identity Manager
  • Oracle Access Manager

Just like the problems you’re trying to solve, these packages range from simple to highly complex, as does their integration with your enterprise. Each approach has its strengths and weaknesses, and those attributes will be magnified by the needs of your organization. But it’s good to have choices.

Finally, if you take nothing else from this discussion, realize Security is a huge, complicated, and ongoing topic for your enterprise. Better get busy.

Share This