Security Analysis

With the massive shift to working from home we now see a plethora of tech companies flogging new employee surveillance tools. You can readily see their appeal to command-and-control thinkers. If you think, as they do, that managing employee activity is crucial, then to know who’s doing things and who’s taking the mickey is grist to their mill. But these tools will undermine performance and morale.

Think about it from the employee’s point of view. Your boss can see your emails, any documents you read or create, your appointments, who you talk to, and when; can listen to or read transcriptions of your calls. Your boss can see your computer screen, can monitor your internet use, the sites you visit and for how long. Your boss can even turn on your camera and watch you at work.

Personally, I believe the best approach to enterprise risk and security management (ERSM) is to rely on several open standards, most notably the ArchiMate standard for enterprise architecture modeling, as well as the Open FAIR standard for information risk management. More details are described in The Open Group’s white paper on modeling enterprise risk management and security.

 In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there’s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.

When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password protection, firewalls, virus detection tools, and the like. These are, in fact, not security requirements at all but rather implementation mechanisms that are intended to satisfy unstated requirements, such as authenticated access. As a result, security requirements that are specific to the system and that provide for protection of essential services and assets are often neglected. In addition, the attacker perspective is not considered, with the result that security requirements, when they exist, are likely to be incomplete. We believe that a systematic approach to security requirements engineering will help to avoid the problem of generic lists of features and to take into account the attacker perspective. Several approaches to security requirements engineering are described here and references are provided for additional material that can help you ensure that your products effectively meet security requirements.

In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges.  This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models

The reason is simple, anyone involved in Information Security needs a detailed understanding around how things work; where the dependencies are, the inner workings of programs and applications, who has administrative control over sensitive information, where the information is being stored, and how clients and programs interact with the data.

Performing threat risk assessments (TRA) involves an intimate understanding of a solution or service. This means everything from the pretty UI right down to the bits of code your development team scribed to make it look that way. 

The only way to understand these systems is via detailed communication with stakeholders, architects, business analysts, systems and network administrators, executives, clients and their technical resources, board members, vendors, ISPs, and the list goes on.

Here we are, the end of another year, and the question I ask always is, what have we learned?

If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?

Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store.

A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting.

The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.

It’s Monday morning and, as you arrive at your desk, you know that it is going to be a busy day. The new portal project is going to be promoted into production in a couple of weeks and there are still a few items to clear up.

As you fire up your e-mail client and take the first sip of coffee, your shoulders start to tense up. The subject line of one of your e-mails reads “Threat Risk Assessment Finding Report” and it is marked important.

This not the way you wanted to start the week, but you remember the report was due on Friday, the day you decided to “call in sick”.

As you open the message, realizing you can no longer avoid it, you cross your fingers hoping it won’t be too bad.

Then you remember why you hate these reports so much, they are confusing and seem overly alarming in their findings.

Critical, Severe, High, Medium and Important findings all over the place, red, orange and yellow screaming in your face, reams and reams of technical output, patches missing, vulnerabilities exposed, buffer overflows, exploitations amok, privilege escalations, and on and on. Oh your head hurts now.

Where do you begin? What’s important, and how much is this going to push the timeline back? You know the launch is in two weeks and there are functional issues that need to be addressed, there is no time to deal with all this!

Every career has a set of skills that one needs to do their job, and a set of tools to carry out the various tasks required to display their skills. Same is the case for the analyst involved in security assessment... I have chosen the all mighty checklist as my tool of choice for this article.

As business professionals, we need to understand that security is everyone’s responsibility; and that is especially true for business analysts, project managers, systems analysts, and others in the position of defining processes, technical architecture, or decision support.

If you are involved in a project that deals with information business assets, then you need to be thinking about the confidentiality and integrity of those assets throughout your project.

There are questions you need to be asking yourself, as well as others on the project, to better understand the security implications of a particular process, technology, or design element of that project.

In my last column I introduced you to the role of a typical security analyst, and explained that security is a part of the business lifecycle. In this column, I will dive into that concept, and I will highlight some of the areas a security analyst might play in determining the risk to an asset throughout its life span.

So what is a ‘lifecycle’ in business terms? There are many definitions, and if you ask any modern analyst you will get their own tweaked version of that answer. For our sake, let’s say a lifecycle is the cycle of life of a business asset from birth through to an end stage.

That unfamiliar voice at the table was an IT Security Analyst, facing a common challenge in the modern day business, getting the project implemented, while ensuring the right security controls are in place.

Where a Business Analyst typically looks at requirements for a project to meet the objectives of the business, or a Systems Analyst looks at the needs of the technology to enable the business to meet the objective, a Security Analyst has too look at the dream.  The “dream” encompasses “we would like to make money” to “we are opening up this firewall port” and everything in-between.

The overall goal of the Security Analyst is finding and mitigating risk to the business, the businesses assets, and the technology infrastructure both current and future. We need to take in an insane amount of factors in about a project and calculate threats, vulnerabilities, and the likelihood of exploitation of these. Mix it in with a little gut feelings based on experience, and inform the business that what they want to do may introduce or magnify risk to their organization.

Software security remains a hot topic. Everyone from grandmothers to Fortune 500 companies has heard the stories of identity theft, data loss, and general mayhem caused by viruses and attackers on the Internet. In the first quarter of 2008 alone, 1,474 different software vulnerabilities were reported with only 64 of them having posted solutions. Th...