Security Analysis

2186 Views
0 Likes
0 Comments
 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.
Jul 17, 2017
2911 Views
5 Likes
0 Comments
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.
15301 Views
11 Likes
2 Comments

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

8346 Views
1 Likes
0 Comments

In a large enterprise, communication is complex and full of red-tape; e-mails, conference calls, meetings on top of meetings, memos, document management portals, and so on.

Wouldn’t it be nice to find a single resource that has all the answers?

8491 Views
3 Likes
0 Comments

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.

6134 Views
1 Likes
0 Comments

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!

9041 Views
1 Likes
1 Comments

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.

 

10917 Views
4 Likes
1 Comments

If you have been following my column over the past few months you should have a pretty good idea of where and when security comes into play for a typical organization.

Something that needs to be said however, is, that not all organizations have a dedicated roll responsible for security. Even if there is a dedicated roll, that person can’t be in twenty places at once.

In organizations that have dedicated teams of security personnel, like a financial institution, the challenge of having a security representative for each facet of the business becomes very challenging as there are dozens of project teams, offices, and operational issues that need to be tended to.

So what do we do?

If a formal representative can’t be present in a meeting or planning session, do we just forget about security?

The answer, I hope is "No, we don’t!"

Author: Stewart Allen

7349 Views
1 Likes
1 Comments

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.

5075 Views
2 Likes
1 Comments

How many times have you been at a project meeting, maybe a status update meeting, and heard a voice that isn’t familiar to you speaking up for the first time.

“Ah... we need to put 5 days in the project to do our VA”

A meeting room full of people turns their heads and looks at the face of the unfamiliar voice. “You need what?” the Project Manager barks.

“We need 5 days, you know, between the build and go-live for the VA.”

A Sr. Business Analyst with many years of experience pipes up, “That just won’t work. We need that time for the QA and sign-off.”

The PM, who has worked with the Sr. BA on other projects, shakes his head in agreement, “We just don’t have time for a VA, what ever that is, now let’s move on to the next item.”

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.

Author: Stewart Allen

4199 Views
0 Likes
0 Comments
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...


Upcoming Live Webinars



Latest Articles

The Elevator Speech... for the BA
Nov 12, 2017
2 Comments
A BA walks into an elevator, is joined by an executive, and suddenly the executive asks the BA, “So, what are you working on these days?” ...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC