OSA Roles

[OSA_BB_Admin]

In OSA patterns we refer to a number of generic roles, we call them actors. To ensure the consistency between the patterns we collect the description of these actors centrally.

We are still evaluating which would be the best primary reference model. The selection of the reference model is subject to the following requirements:

* The model must have security relevant actors
* The model must be publicly available (without costly corporate membership rates)s
* The model must be used across several industries/countriess
* The model must NOT be driven/owned by a single company

Potential candidates for the models are:

* Roles within CLASP
* Roles within ITIL v3

Please contribute your experience in this discussion thread....

Thanks

[gadazhb]

Roles within CLASP

[spinoza]

What basis would you vote for CLASP? Higher quality? Better coverage? Wider acceptance?

It seems important that the roles should be widely understood by people outside of the security architecture community, e.g. Business analysts, Architects and Project Managers and Developers if we are to gain wide traction.

I think perhaps ITIL has a wider acceptance?

Cheers,
Russ (Spinoza)

[esiewick]

My vote would be, neither. Two reasons.

First:
Neither CLASP nor ITIL provide a complete set of roles. The two together don't either. You'd need both and then some.

CLASP is concerned with the architecture and engineering of secure systems. It has roles relevant to the design and implementation of security controls early in the SDLC. A lot of the SP800-53 (original, rev1,2,3) controls that require documentation of an engineered solution. Several in AC, AU, IA, SC are of this sort.

ITIL is concerned with IT operations; describing and performing specific processes, managing existing environment, and controlling changes. ITILv3 barely mentions "security" with perhaps a dozen pages in the "purple" book, and then only in the context of well defined services. Specifically, CM, CP (or does it only mean DR?), IR, CM, and more CM.

Between the two, CLASP and ITIL, there still seems to be quite a gap. The larger organizational roles aren't in this combined set. So a lot of RA, CA, and really all the *-1 "policy" controls are missing key actors. There might be a mission owner in CLASP somewhere. I don't believe ITIL has anything higher that the IT shop floor boss, though. So if you need an enterprise level policy owner you'll have to invent him; he's not in the current set. AU-2 for instance wants a list of auditible events on which a number of other controls are anchored. There's no role in CLASP or ITIL with sufficient authority to decide what events the mission should care about.

Second:
Something else is needed. It might be, an adjustment to the level of detail to which the roles would be defined. I strongly believe that common patterns of controls exist, and should be documented. However, prescribing highly defined roles for controls gets rather far in to implementation specific detail that should really be left for the individual organizations to sort out. All controls give the "what." Some might even get in to the "how" via of some external policy requirement (FIPS). It's a very rare control that prescribes a "who," though.

[spinoza]

Fair comments. The intent of introducing the roles that you currently see in the server pattern (for example) is to cluster controls into meaningful groups and make the pattern easier to comprehend and implement.

However on reflection I woulda agree that it is hard to find a universally agreed set of roles with respect to controls, e.g. not all practitioners would agree that control X maps to role Y.

Perhaps the value comes in a broad classification between development & engineering, operations and governance. NIST as standard gives us Management, Operations and Technical which is pretty much the same:
Management = Governance, Operations = Operations, Technical = Development & Engineering.

Therefore for now, until the need for roles is established, I suggest we leave and simply cluster accordingly to the NIST groupings where this simplifies a pattern.

Russ.