Call us at 507.319.5206 or This email address is being protected from spambots. You need JavaScript enabled to view it.
Follow us on LinkedIn and Twitter

Security’s Little Shop of Horrors

OR… How to Recognize the Threat in the Seedling

You regularly read news of security breaches, right? So why are all these businesses – large and small – getting hacked, cracked, and/or extorted by ransomware?

It’s really not much of mystery. It’s a natural result of how organizations tend to view and manage – or should I say mis-manage – security over time.

You can help your organization recover from security mismanagement and protect its IT assets if you understand how your current security practices came to be and how they open your system to serious security threats.

In the Beginning…

Most organizations start small, with a few people wearing many hats. They don’t have much in the way of information/ IT assets to protect. All of the organization’s data might be on a couple of workstations and, maybe, one server.

Security is relatively straightforward, right?  Get a good antivirus product and firewall and get on with getting business for the organization. You don’t really need a formal information security management business process because there’s just not that much information or that many people.

One person acts as the “IT guy/gal” because they aren’t really afraid of computers and can make them do the things that are necessary. Everyone just needs access to the few IT assets that exist so they can focus on making the business a success.

This is when the seed is planted.

The Seed Germinates

As the organization grows, so does its staff, the amount of data it has, and the IT assets required to manage that data.

IT grows, too, because there is more information to manage and more business processes to automate, resulting in more sophisticated applications; some developed internally and some purchased from 3rd parties.

This is the point where C-Suite executives — though they often don’t know it — need to step up and begin to treat security as an important business function. Specifically, they need to establish a full-fledged process to manage information security, assign staff to roles within that process, and ensure the process is being executed.

If this is not done, important business decisions — such as whether the administrative assistant in accounting should have access to the accounting data and whether s/he can access that data only through the application or via any interface on the system — get made by people with a purely technical background. The more this happens, the more risk you incur.

By default, executives abdicate their responsibilities. This leads to virtual anarchy in security; especially at the system level – where all the valuable information is stored.

The Care and Feeding of Security Vulnerabilities

The organization continues to grow. The old system administrator is promoted or leaves the company.

The development team is heads down trying to make some progress on their long list of projects. They may put in some code for authentication, but for all intents and purposes they leave access control to the system administrator.

Developers don’t understand that they can build their apps so the system administrator can significantly reduce risk while doing very little to manage access control for a large number of objects and users. And no, they don’t have to give everyone who can sign on to the system access to every business object in order to minimize management!

Things are now so complex in the IT shop that business leadership is convinced more than ever that security is a technical issue. They feel incapable of ensuring that the proper security decisions are being made by the appropriate individuals.

Meanwhile, the new system administrator has learned that her job is to make sure the system stays up and the applications don’t have any “system-related” problems that prevent them from running successfully.

Authority failures are assumed to be solely in the realm of system administration.

When one occurs, the only question is “how do we ensure that this doesn’t happen again?” And they usually choose one of these simple fixes:

  • allow everyone to do anything to the object on which the authority failure occurred
  • ensure that everyone who encounters this problem is given privileges to access all objects

Problem solved. No more authority failures. But your back door is left wide open!

You see, the new system administrator has no idea which employees need to access which data. They may know which application(s) various employees use, but they don’t have a clue as to which objects are used by which applications for which purposes. They certainly don’t understand the application architecture.

Add to this their primary responsibility – Make sure there is no system or application downtime. Ever! – and you have the vulnerability that large numbers of IT shops face today.

We’ve Created a Security Monster

Now the organization is large. Nobody really understands why anything is secured the way it is. They assume that “this is the only way it will work” and they are deathly afraid of making any changes because they have no idea how a security change might affect anything.

Admins don’t have time (or sometimes the skill) to analyze an application in enough detail to mitigate their fear of breaking it. The development team, who could provide insight, still has a huge backlog. The last thing they want to do is analyze how their own “legacy” applications work.

They also assume, incorrectly, that the best thing they can do is to make the same decisions for every person and every object that had been made in the past. Of course the management team believes this without asking any questions because who are they to question the technical team about technical decisions and estimates?

The Data Hits the Fan

I’ve seen this a thousand times in multi-national banks, nation-wide retailers, pharmaceutical companies, health care organizations, utility companies, etc.

Security continues to be viewed as a collection of settings rather than a business process. It’s way too complicated. It costs too much. It’s a productivity drag. This is even true for organizations engaged in security projects such as PCI or HIPPA/HITEC compliance. You can spend a whole lot of money and you are probably even deemed compliant, but you still have huge security holes of which nobody is really aware.

This leaves companies wide open to mischief or worse.

How to Establish a Security Management Process

The only true solution is to approach information security from a pure business perspective — to define exactly who needs access to sensitive data and to communicate various security roles and responsibilities to each person in the organization.

Where do you start? We typically recommend the following to our clients, with an offer to mentor them through the process and/or implement specific steps.

  1. Perform a risk assessment to identify weaknesses in your current system.
  2. Use this data to convince the C-suite to accept their rightful roles in developing a security management business process: to champion the process and ensure it is being properly executed by the appropriate people.
  3. Work with the C-suite to establish a formal information management business process.  Outputs of this process include goals and objectives (e.g.security policies).
  4. Determine the most efficient and effective ways to enforce the policies and to mitigate any gaps in enforcement while maintaining productivity.
  5. Implement and monitor the new security procedures.

Once you get through this process, it’s much easier to maintain an effective security process a matter of monitoring, measuring and adjusting. Much easier that throwing security switches blind-folded

Let me know if you could use help with this process.

 

Facebooktwittergoogle_pluspinterestlinkedinmail
This entry was posted in IBM i Security, Info Security Mgmt, Security Breach and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>