The Connected Information Security Group : Software Requirements

Designing Whole Systems

cisg — Fri, 12 Sep 2008 19:42:34 GMT

Hi Dennis Groves here......

Recently I was questioned over a comment I made about a USB key being functionally equivalent to a Smart Card in a discussion about bit-locker. I of course not understand that they are technically not equivalent. Smart cards have their own operating systems and USB keys don't. And that is huge; the costs associated to break the a smart card are far more than the cost of the system itself!

The situation may have been that the folks questioning me see the technology. I not only see the technology but I see the architecture and the behavior of people. Security is about people, process and technology.

In terms of the bit-locker architecture; both the SmartCard and the USB key can be used as an authorization token to use the drive by decrypting it. They don't establish the identity of the user; only the right to decrypt the drive. Both are two factor authentication tools. This is way better than passwords and I am 100% supportive of moves in this direction. However, the smartcard is thought to be better for reasons noted above; but also because the issuer of the smartcard has shifted the burden of their risk to holder of the card. This is one of the three ways you can manage risk; transfer it, mitigate it, or accept it. Smartcards are so good that if somebody was to be motivated for your secret; they can not just steal or clone your card anymore; they have to do a little rubber-hose crypo first (just kidding of course). Fortunately, such methods are generally not necessary as social engineering is a far easier way to steal credentials.

And after the system fails either because of dancing pigs, rubber-hose cryptanalysis, design flaw, bugs, side-channel attack or what have you; your left with functionally equivalent protection.

The problem is that security is not about a technology; and we very often forget that. Security is about mitigating risk, and it is about the people and their behaviors. When you design systems you have to really think about how the system and the people behave as a whole. And most importantly you have to design them to remain secure when the fail. You must assume failure. Sooner or later the system will fail. If not because of dancing pigs, then because of rubber-hose cryptanalysis.

A friend of mine Nigel Tranter used to have an email signature that read "The attacker only has to be lucky once, you have to be lucky all the time!"

It is worth repeating that security comes from a system in its entirety; not from a single component of that system. Currently most systems in require frequent patches, and have unknown, undocumented vulnerabilities. Things are of course improving.

Therefore, Dennis says "the way to build secure systems is to build with failure in the design."

Its about designing whole security solutions!

Trip Report : Day Two of Gartner BPM Conference

cisg — Fri, 12 Sep 2008 12:18:43 GMT

Hi Marius here again with highlights from day 2 of the Gartner BPM conference.

Back of the Napkin

You may have heard of the book called The Back of the Napkin: Solving Problems and Selling Ideas with
Pictures. It’s one of the latest books creating a buzz in business community. Dan Roam, the author
of the book presented on how the most daunting business problems can be described simply using
only stick figures in the space of a few square inches available on the back of a napkin. Ultimately,
those who present the problem the best get the funding to proceed with their project. Dan argues that
there are three types of people. Those who immediately jump to the whiteboard and start sketching
in meetings (25% of us), those who are not artistic BUT will highlight what’s interesting (50% of us), and
finally those who are not artistic and simply refuse to participate in the process (the remaining 25%).
Those who highlight don’t come up with new ideas, but they are good at dissecting ideas presented to
them and highlight what really matters. Those who refuse to sketch do so because they understand
that what’s being drawn is far too simplistic to be reality. These people tend to have the most facts on
the problem. When they compare the drawings to their own information, they are turned away from
the conversation. The challenge is to find a way to involve these people, and the solution presented
was to (don’t read if you’re this last type ;-) ) to get them angry enough at the situation that they take
control, cross out the irrelevant information, and find a way to distill their facts into a way that fits onto
the drawing. Dan argues that visual communication transcends language and cultural barriers and can
be used to communicate complex ideas – but these ideas need to be transformed into a combination
of the following: who/what, how much, where, why, how, and when. After talking a bit about
neurobiology, Dan explains that the brain has different visual pathways for each of these types of
information that are all processed in parallel. How can you present each type of information visually?

Just follow this chart:

The story given was that Dan had to present the problem statement around a financial process in
Microsoft. He drew the problem statement on paper using stick figures and didn’t manipulate
the image through Illustrator or any such tool. The execs were impressed because he was able to
easily relate to them and they asked what software he used. Facetiously he replied “Pen and Paper
1.0.” The moral of the story however, is that the more human your presentation, the more human the
response will be.

Next time you need to speak to your customer about pain points, try the following Wong-Baker pain
chart, used in emergency rooms:

BPM Modeling

The next session was about BPM modeling by one of the leaders of the BPMN standard. BPMN is a
powerful standard that can be used to model almost any business scenario. It is an easy to use way to
draw processes designed to be understood and used by business users. It’s limitations include not
being able to model meetings (without resorting to an ad-hoc task) and serializing the model.
Serializing is necessary to be able to save the model in a way that is executable by a workflow engine.
Workarounds to the serialization issue are to export the model as XPDL or BEPL. Despite these issues
BPM vendors are retrofitting their tools to support BPMN 1.1 due to its power in modeling processes
and simplicity for business users. Want to give BPMN for a spin? Try the free tool:
http://bizagi.com/eng/products/ba-modeler/desc-efective.html

Risk Management and Compliance

This was the one must see track session considering what our team does and I had to trade off several other
good presentations to attend this one. The key point delivered was that GRC is a short-term audit-driven need.
Nobody likes compliance (except for those whose jobs are compliance) but thanks to the likes of
Enron and MCI WorldCom we’re in an ever increasing regulatory environment where imposed
regulations continue to grow. Businesses really wants performance and business risk management but
for now they are faced with immediate needs to track regulatory compliance. GRC tools out there
include some form of process, but they are still stovepipe applications. In the next 4-8 years, expect to
see BPM solutions move into the GRC space. Strengths of BPM in the GRC space are the fact that you
can set risk management workflows, perform policy mapping, model (and simulate) risks and controls,
automate controls, and analyze control effectiveness. In our experience, creating management
workflows and analysis of control effectiveness are some of the hot topics in the risk management
work. The weaknesses of BPM in the GRC space is related to domain knowledge and time to
implement. The primary drivers of GRC implementations today are the need for domain knowledge of
regulatory standards (something that BPM vendors do not have experience in) and a quick audit-
driven solution – customers need a fast solution, not tools that enable them to create solutions. Since
“pure” GRC is a short-term need, the industry will begin to focus more on risk management, and
eventually business performance management. Since BPM is already in the realm of performance
management, the prediction is that BPM suites will start to include risk management and modeling
capability with compliance built-in to ensure that processes created through the tool are in
compliance.

User Interface and Empowerment Disrupts Business Applications

From the start, it was a surprise to see how few people attended the keynote on user interfaces.
Rather, most attended the session on change management instead. Since my double was not available
at the time, I had to pick one or the other and went to the only session related to UX. The problem
statement presented is that the returns on automation are shrinking, mostly due to the fact that business
applications have already squeezed the people out of processes in most places. Many of the
remaining tasks end up being non-routine, highly cognitive, and interactive tasks—and this trend is
growing. In second place are non-routine, highly cognitive, analytic tasks. Both of these types of tasks
are poor candidates for process automation. What should IT to do in these areas? Industry wide, IT is
already being seen as an inhibitor to business change.

The answer is to model processes around business KPIs (not the opposite) and empower the business
user to have information at their fingertips and to “design” their own solution:

• Focus on End-User Flexibility

- Enable end-user process flow design

- Enable end-user-driven creation of apps through configurations, personalization,
mashups, compositions

• Develop a Consumer like Experience

- Embedded user experience that includes Web 2.0 and user productivity like
experience

- Immersive UI, pervasive mobility

• Incorporate Context Into Processes

- Peer-based, ad hoc collaboration enabled

- Community-generated content

- Process and information design presented based on individual need

• Include a Network-Centric Design

- Anyone can participate, from any organization, from any geography

- Architected for high-volume, highly distributed, simultaneous connections

- Information can originate from anyone, anywhere — no boundaries

• Provide Actionable, Intelligent Insights

- Predictive, proactive and context-aware analytics

- External and internal cross-application content

- Structured and unstructured data analysis/synthesis

In the end this is really the people component of people, process, and technology.

Thanks for reading, more tomorrow.

Marius

Trip Report : Day One of Gartner BPM Conference

cisg — Fri, 12 Sep 2008 12:11:00 GMT

Marius Grigoriu here....

I am a Program manager with CISG and in keeping with good program management its straight down to business. Today was the first official day of the Gartner BPM Conference at Washington DC and I am posting daily trip reports. In the Connected Information Security Group we believe that BPM or Business Process Management is key to the future of information security management.

Three recurring themes emerged from the different presentations given today:

1) Staffing

2) Agility

3) Continuous process improvement

Themes:

Staffing:

Getting the right mix of people working on the BPM project is critical for success. Just throwing the smartest people in a room is a recipe for frustration without the proper roles, skills, and authority. At a minimum, BPM projects should include a business process owner, implementation lead, developers, SMEs, and an executive sponsor. The business process owner is the team member belonging to the business who has knowledge of the business process and has the authority to make changes to the process as necessary. The process owner defines the process being input into the BPMS and also drives adoption of the system in the business organization. The implementation lead is much like our program manager role on the CISG team. They work with the business process owner to model the process, collect other requirements, drive the creation of the solution. Somewhat misleading is the title as an implementation lead does not drive adoption within the business, but must work closely with the process owner to accomplish the task. “Developers” are not just devs, but includes the entire team necessary to support the development effort: architecture and design, development, testing, and appropriate management. Not mentioned were the IT operations staff members who should also be included and finally is executive sponsorship. SMEs are the team members who know the most about the as-is process including any undocumented and unofficial processes still necessary to their team’s operations. The executive sponsor must be dedicated and willing to make hard decisions to push the project forward. By nature process decisions are decisions about people’s jobs, which can become contentious at times. It was mentioned that an absent or hesitant executive sponsor is a show stopping danger sign --the executive sponsor must be 100% behind a BPM implementation project to succeed.

Agility:

Multiple speakers have mentioned the important of agility in implementing BPM. First, one of the general goals of BPM is to enable businesses to improve (read change) their processes through the collection of data and to decrease the cost of IT changes (vs. the monolithic LOB app). Thus one of the points of implementing BPM is to facilitate business change and agility. Next is that waiting for perfection in requirements and process documentation/modeling is counterproductive. Teams may contains unknown, unofficial sub-processes which are hard to discover even with SMEs on the team. At some point, perfecting requirements and designs require much more time for an incremental change in value. Playbacks such as rapid prototypes and iterative releases should be used to frequently obtain feedback along the journey. It is important to note that iterative releases are not the same as planned staged releases. The latter is executing on a pre-determined plan created with information from the early phases of the project. The former is about inspecting the work delivered, identifying gaps and areas of improvement, then addressing those issues. A BPM project is not a “once and done” implementation project like many other IT projects that are developed then put into sustained engineering mode. Even after iterations have completed, one or two dedicated resources will need to be available to handle continuous improvement process changes.

Continuous Process Improvement:

Related to agility is CPI, the #1 recurring topic so far and one of the big benefits of implementing BPM. CPI is made possible by the metrics and process visibility created by implementing and running BPM solutions. However this implies that resources need to stay on project after implementation to make the changes resulting from additional process analysis. As processes change, so will the system, and the BPM implementation needs to be build in a way that can accept change. Re-useable components and the use of BPM/rules engines to move away from business logic built-into application code have been mentioned as a way to achieve lower IT change costs.

10 Habits of Successful Organizations Building BPM solutions:

1. Make BPM about productivity AND visibility:

Metrics, KPI, SLAs, should be part of the defining the process
Try not to scope out metrics

2. Integration

Don’t underestimate the effort required to integrate systems and start early
But don’t get bogged down either – don’t let that delay your first project (which should be a low risk, high impact project)
Be ready to trade off integrations that stand in the way of a timely release

3. Never a “one and done” project

Iterative approach to process improvement and bpm systems

4. Don’t skip process analysis

Requirements are not the same as process analysis

5. Take time to deliver value

Taking longer than 90 days to deliver is not a failure
Use timeline as a box in which to deliver your value

6. Build a complete team

7. Self-sufficiency is a priority

FTEs are necessary to build organizational capability
Partially allocated FTEs are not good enough – they need to be committed to the project

8. Fund to value, not just the first release

Big challenge as IT funding tends to be per project usually just for a first release
To obtain the benefits of CPI, maintenance should is not a sleeper like for may be in other applications

9. Force collaboration, use playbacks and iterations to create tangible results for frequent validation

10. Set owners for the program, process, and technology

Thanks for reading, lots more tomorrow.

Marius

It’s All About the Persona(s)

cisg — Fri, 12 Sep 2008 09:38:54 GMT

Birm here…

Has this ever happened to you? It’s happened to me. You sit down to write an application that looks great and works even better. The UI you’ve designed is a model of esthetics and efficiency. You’ve demo’d it to the developer in the next cubicle and she’s loved it! Then you hand it off to a real-life user and it falls flat. Like a run-over pancake.

When we sit down to code an application somewhere, somehow there is a person who’s eventually going to be using it. Usually that person starts out as -- and too often remains -- a figment of our imagination. What we’ve done is what Alan Cooper calls in his book, The Inmates are Running the Asylum, “bench development.” That’s where the “user” we’re coding for resembles the guy sitting at the next bench. A guy who may be writing another part of the same app as you are, and likely with a vastly different user in mind. Instead of developing applications for one or more well-defined and well-understood personas, that guy and we each go our separate way, never taking the time to communicate and agree on what and who our true user is.

The major malfunction is that we as developers and designers have forgotten a basic, immutable fact: we are not our users.

Enter Personas

When a problem arises that lends itself to a computer solution, there’s usually a specific business need underlying the problem. It follows that there must be a diverse and yet specific constituency for that solution. A computer program useful to a mechanic will be useless to an animal trainer…and vice versa.

A persona is a representative archetype that models the kind of people who will be really using our application. An archetype which is qualitatively and quantitatively validated so that we know that we can rely on it. An archetype described in such detail that every developer on the team feels like they had lunch with that persona just last week.

The first step in creating a persona is to unambiguously decide on what kind of person(s) would be included in the constituency for your application. Then you go find several of those kinds of person and talk with them. You ask them about all the things that would be helpful in designing an application that would be useful for them. For example, what exactly do they see as being their occupation? What are their goals as they perform their work? What information do they need to do their job, and in what form? What are their day-to-day frustrations and pain points? How, and with whom do they communicate to get things done? What you end up is a list of characteristics and attributes that you consolidate into one or more personas.

One final thought: to create a persona and to create fiction are two disparate things. For a persona to be reliable and actionable, it must be a truly representative archetype, with nothing about it pulled out of thin air. You can consolidate characteristics and attributes, certainly. But they must first actually exist in the group of people you interviewed to get the data to create the persona.

Checklists and Mnemonics

cisg — Fri, 05 Sep 2008 19:56:37 GMT

Dennis Groves here....

The most common list is the to-do list, and it is the one we are all most familiar with and so the real value of a checklist is often very misunderstood. Aviation and medicine make heavy use of them. Computer programs are basically a sequential list of operations to for the computer to perform. In computer science; the linked list is considered to be a fundamental data structure. However, its most basic component is the list. In fact there is an entire computer language that is composed only of lists. And an entire branch of mathematics. The list is such a fundamental tool that most of us take them for granted and think nothing more of them. And yet we would be doing ourselves a great disservice to dismiss the usefulness.

Mnemonics are a kind of list used to recall important information. Recently I read a brilliant post by Adam Arndt about "SOAP"

The SOAP method involves putting all data concerning a problem into a “SOAP Template”, that is to say that all data should be entered underneath one of 4 headings (the first letter of each heading spells out the acronym “SOAP”):

Subjective, Objective, Analysis (or “Assessment”), Plan

Subjective information is filled out first and should contain subjective, qualitative information about the problem. Examples: “The network is slow”, “Outlook “hangs” when I try to send an encrypted email”, “I feel sick”.

The Objective information is filled out next and should contain verifiable/verified quantitative information that provides further insight into the Subjective information that the customer/patient has provided. Examples: Event ID’s from event viewer, errors displayed on the user’s screen, log files, packet captures, version information about software, programming languages used in code, functions used in code, % CPU utilization, blood pressure, body temperature, and heart rate statistics.

Analysis This is where you use your brain and analyze the Objective data that has been gathered and attempt to find root cause. One result of the initial analysis may be that you do not have enough Objective information to solve the problem so you ask the customer for additional Objective information that you need to continue the Analysis. This is an important part of the case documentation process as it should track any actions that have been attempted/investigated so that if another engineer must take over the T-shooting process the same actions are not performed multiple times. The final output of the analysis phase should be the discovery and documentation of the root cause of the issue.

Plan A list of possible mitigations for the problem. A list of possible ways to resolve the issue with their pros and cons laid out. (In some situations only one solution may exist.) The customer will then choose which solution to implement (we’re just consultants, not their business decisions makers we don’t make decisions for customers, we just inform them of their options and the pros and cons and they must choose which one works best in their environment), this decision should be handed off to the customer’s Release Management process and, especially when we’re doing consulting for the customer we should make sure that the customer understands the Operational Impacts surrounding that change.

The utility of such a pattern in problem solving is really amazing. For example lets say your worried about saving for the children's university education? SOAP to the rescue. Subjective: your fear you don't have enough money. Objective: look in the bank; have you started a college fund? Analysis: Not enough money for their education. Plan: Set aside money for the children's education every paycheck. Wow! That is a really useful pattern. And yet this was ostensibly invented to reduce medical malpractice law-suits by getting doctors to collect information in a consistent manner so that nothing was forgotten in times of emergency.

I find these kinds of patterns to be useful and exciting; as does my friend J.D. Meier who has a blog devoted to the documentation of such patterns and insights.

Doing What You Want, Not What You Have To!

cisg — Fri, 05 Sep 2008 18:22:17 GMT

Birm here.....

As I go about my daily routine, I talk a lot with people directly involved in software design and development. It’s become clear that based on their training and experience, each person has a different take on what constitutes “user experience.” And while they have an idea of usability, they’re not well schooled in how usability is achieved.

Usability – good usability -- is a concept which is at the very heart of a great user experience. That being the case, and given that we’re just getting started with our blogging on user experience, it seems the right thing to do to step back a moment and agree on its definition. I’ll try not to be too tedious as we go about this…but we’re laying a foundation here, and it’s important that we all really understand usability in the same way.

The International Standards Organization (ISO) published back in the early 90’s a standard having to do with the ergonomics of first visual display terminals (remember them?). ISO 9241 has evolved from discussing simple VDT’s to present-day computers. It now includes standards for the usability of software. To be specific (pun intended), ISO 9241-11 says that usability is “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.”

They expand on this in another part of the standard. Notice the three words I italicized in that paragraph. “Efficiency” refers to the accuracy and completeness with which a user achieves their goals. “Effectiveness” has to do with how much effort the user has to do so. Finally, “satisfaction” is about how happy a user is with the tools they have to employ to get to their goals. In each case, it’s all about how well everyday people are able to interact with the products you design and build.

The Usability Professionals Association (UPA) – a group of which I am proud to be a member– says usability is, “an approach to product development that incorporate direct user feedback throughout the development cycle in order to reduce costs and create products and tools that meet user needs.” Here we see a point of view of people who are trying to get across to business decision makers the value of incorporating validated usability into their products. Turns out that the argument is actually a fairly easy one to make. There is a demonstrable ROI to usability, and we’ll be talking about that in a later blog.

Back around the turn of the century, Steve Krug wrote a really great book called Don’t Make Me Think. His definition gives a more personal perspective to the concept. Krug says, “Usability really just means making sure that something works well: that a person of average (or even below average) ability and experience can use the thing – whether it’s a web site, a fighter jet, or a revolving door—for its intended purpose without getting hopelessly frustrated.” Not a lot of us have flown fighter jets. But I’ll bet that more than once you’ve pushed on a door that the builder expected folks to pull open instead.

I’ve saved the best definition for last. In his book, User Centered Web Design, John Cato defines usability as “…being able to do the things you want to, not the things you have to.” And that friends, is what usability is all about. If with our applications, our customers get to do what they want how they want to do it, then they’ll have a great user experience.

It's just as simple -- and just as complicated -- as that.