Tuesday, 02 February 2016 01:43

In Security

Written by
Rate this item
(0 votes)

Let’s face it. It’s all about information. Everything we do is about information. We need information to do our job, and our job is usually about information, information that is collected from a wide range of sources over a long period of time, information that is created through the combination of other information, information that is printed, displayed, organized, manipulated, and stored for decades if not eons.

And that information is important. We depend on information.  We use information to know what is going on, to make decisions, to entertain us, to communicate, or simply to take us to places we’ve never been. It’s all about information.

It’s all about information security

And then, it’s all about security of that information; who can see it, when they can see it, how much of it they can see, and in what form will the information be kept and for how long? Should the information we need be secure and to what level? Should it be private, and private to whom? When should it be released? How long should it be kept before releasing or destroying? Can it be destroyed?

Security. Even in IT, we tend to view security as a specialist’s area. Security people are strange birds, and security “stuff” is generally the bailiwick of specialists who think differently than the rest of us. They have their own vocabulary - black hat, white hat, encryption, public and private keys, breach, vulnerability, hacker, cracker, malware, and so forth. As Business Analysts, and even as Developers, information security is viewed many times as a layer of nonfunctional requirements and / or software added to the basic business requirements at some later date in the software development lifecycle.  And in many cases that is the way it has to be.

But consider this; a breach in security is bad for business. Loss of information is not simply an IT issue; it is a business issue.  The loss of information might well lead to the loss of the entire business. Security requirements are business requirements. Consider even further - the level of security is based on the value of the business assets being secured. Therefore, it is necessary to analyze the business assets to determine the value of those assets and what levels of security are necessary. Note the words “analyze the business”; in other words, business analysis.

We are all insecure

The reality in information security is that there is no foolproof way of securing the business’ information except by physically disconnecting all the information from any external access.  In other words, “unplugging”. And while that was a perfectly valid business strategy 50 years ago when I started, today the concept of being completely disconnected from the Internet and still being successful in business would be considered far-fetched. (Actually for most businesses back then “unplugging” was not an option since there was nothing to “plug” into. Locked file cabinets containing the business “secrets” sufficed.) In those days, we who defined requirements, design systems, wrote the code, and tested the results were not worried about information security. Security, not just information security but all security (there was no category called information security at the time) was indeed handled by a completely different organization with whom we in data processing (as it was called back then) rarely had interactions. Security back then was focused on physical security, preventing unauthorized access to the premises, and to those locked file cabinets.

A Security Guideline for Business Analysts

Since we cannot, as Business Analysts, developers, or even security specialists, completely prevent an intrusion or a breach from occurring in today’s interconnected spider web of information, we need to have a guideline, a balance between security and convenience, between preventing access by the bad guys and inappropriately filtering out the good guys. If we do business on the Internet, we need to make it as easy as possible for those seeking to do business with us to access the information they need to do business while at the same time preventing those with malicious intent from accessing, manipulating, or modifying our information.

So we have this guideline that was written on a card which I kept pin on the wall of my office in a previous life in security:

Make the cost of the breach exceed the value of what is compromised.

If we are able to implement this guideline effectively we should be able to present the majority of damaging breaches, and pretty much all intrusions based on economic gain. What this does not prevent against those who are attempting to break security for reasons of revenge, “fun”, or simple malevolence. And those areas are indeed the purview of the security specialists, and probably also the psychologists.

However, the general approach will be effective.  Considering that the “cost” includes not only the time, effort, and or monetary expenditures to get to the information, but also the length of time of exposure. For example, the “Club” which many car owners have affixed to their steering wheel to “prevent” theft of their vehicles does not actually prevent theft. Cars can be stolen with a Club on the steering wheel. What the Club does is increase the amount of time the car thief has to spend to steal the car; thus, the “cost” of the theft is in the extended exposure and increased potentiality of being caught. If the vehicle is a Ferrari or some other car that costs six figures to purchase, it might be worth the risk. If the vehicle is my 17-year-old sedan, it clearly would not be. So the “cost” can also be measured in “exposure time” for the bad guy.

To make that guideline work effectively, the business must first have a definition or assessment of the value of its information. Not all information has the same value. And the cost of securing that information should be directly proportional to the value the information has. In other words the organization should spend more time and money securing their customer master files which have national identification numbers and credit card information than in securing the departmental picnic list file that contains the names of employees attending the annual picnic and what dish they are bringing (to prevent too many bags of potato chips and not enough vegetables).



The Business Analyst’s Role in Security

It takes business analysis to determine and assess the value of the information in the organization for any given business process or information system. Since security should not be an afterthought to be added after the systems or changes have been developed, it is up to the Business Analyst to determine the value of the information, all the information, being used by a particular business process or information system. The Business Analyst may not be required to identify threats and or countermeasures which is indeed the domain of the security professional (although I have seen many Business Analysts involved with threat assessment in organizations because of their breadth of knowledge of the business activities, processes, and information.)

The Business Analyst also provides a valuable check and balance to security by identifying when security measures may be too much – they prevent business from happening or make it exceedingly difficult – thus impairing the organization’s mission or keep it from achieving its strategic goals.

Helping the organization become secure

We typically think of security in terms of protecting against malicious intrusion or identity theft. But when we consider the entire business there are many other areas in which security is important to the business. For example, corporate espionage is a threat to many businesses. Privacy of both the employees using the systems and customers entering their data into the corporate databases has been increasing in importance the century and generally falls under security. While security is a policy of the organization to protect the organization, privacy falls under regulations of countries and other jurisdictions and may cause an organization to run afoul of the law.

Many times the solution to a security problem is not additional software or technological engineering, but a simple change in the business process. The Business Analyst is the primary role familiar with the entire business process and is able to identify security weaknesses in the human activities which in many cases is where a security breach starts.

While the technologists will focus on the networks, the portals, the access points, the web servers and other technology-based vulnerabilities in the organization, the Business Analyst can look at a wider picture that includes the movement of information outside the computers throughout the company and the people who handle that information.

It takes a Business Analyst to put a security problem into a business context. It takes a Business Analyst to evaluate whether the assets being protected are worth the cost of the protection. It takes a Business Analyst to understand the human factors involved with security issues and security breaches.

The Business Analyst can provide valuable information to the security professionals to help make their job easier and more accurate thus adding value to the organization (in terms of increased and better security, and a better cost-benefit ratio for the security activities) which is what the Business Analyst is all about.



Read 4528 times
Steve Blais

Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development.  He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250