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.
One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy.
In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration. Now, our attention turns to how data should be defined. Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.
The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.
However, there are some very legitimate reasons for documenting existing systems...
"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."
In this article Ellen covers a number of agile requirements topics including:
A colleague of mine asked me recently what makes a good Business Analyst, and this stumped me for a while. I had a rare opportunity to go trout fly-fishing recently and as the fishing was slow I was able to contemplate this question. You will gather from this that the question had worried me as I seldom think about work stuff when I am fly-fishing.
So what does make a good Business Analyst?
I decided to go back to basics; if I want to know what makes a good Analyst then I need to ask what do we, as Business Analysts, do? If I could understand that, then I can start to understand what makes one Analyst better than another.
I asked around in business analysis circles for an on line description of what we do. Although I got a few different answers, I found I got the most consensuses with “a Business Analyst elicits, documents, and communicates business requirements”. But what does that mean?
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.
One of the biggest challenges in any system design effort is to produce a viable system design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.
In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:
Author: Tim Bryce
“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended. Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.
Author: David Wright
The short answer: "Because it requires work."
The long answer: People tend to resist gazing into the crystal ball and prefer to react to life as it passes them by. Some people believe planning in today's ever changing world is a waste of time, that you must be more "agile" and accommodate changes as they occur. As anyone who has designed and built anything of substance knows, this is utterly ridiculous. We would not have the many great skyscrapers, bridges, dams, highways, ships, planes, and other sophisticated equipment without the efforts of architects and engineers. Without such planning, our country would look essentially no different than how the pioneers first discovered the continent. Although we must certainly be flexible in our plans, and we will inevitably make some mistakes along the way, little progress would be made if we did not try to plan a course of action and control our destiny.
People often take planning for granted, that someone else will be making plans for us, such as government officials, our corporate management, or even the elders of our families. Consequently we become rather lax about looking into the future. Nor is there any encouragement by anyone to plan our affairs, such as a tax break. Whereas other countries offer incentives to save money for the future, such as Japan, America does not. Therefore, planning is a rather personal activity; we either see the virtue in doing so or we do not.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: