Security Approach

The fifth of eight (5 of 8) artifacts in the Solution Approach series is the Security Approach. Basically, this approach connects the higher-level guidance of the Security Strategy with corresponding Solution Delivery content. Additionally, it offers guidance for the design and development of individual Security objectives.

In effect, each Security objective appears as its own Feature in the Solution Backlog. All Security Features, along with their corresponding Stories, relate to the Solution's Operations Epic. This one Epic organizes all aspects of the Solution's Security.

To begin, use a copy of the upper portion of this page as the basis, or template, for this Approach. Thereafter, follow the 'How to Develop the Solution Approach' steps in the lower portion to complete this table-driven (i.e., fill in the blanks) artifact for a specific Solution.

On This Page

Add a header to begin generating the table of contents

Begin Template

Solution Approach 5 of 8 - Security

The series of artifacts outlining an Approach for this Solution continues with Security. Basically, each Approach bridges a gap between the guidelines and guardrails found in its corresponding, higher-level Strategy, and the subsequent execution of iterative Solution Delivery.

By working through this Security Approach, an initiative defines the desired level, and means, by which to secure access within the Solution. Consequently, this helps build the Solution Backlog. Thereafter, subsequent Solution Delivery efforts implement the functionality identified herein. This Approach builds upon that which appears in the corresponding Application Approach. Refer to that document for additional information.

Introduction

The Security Approach describes concepts for managing access to specific functionality and/or data within the Solution. Specifically, this Approach deals with incremental security beyond access to the Solution in general. In other words, Authentication, as described in the Security Strategy, addresses access to the Solution. Additionally this Approach looks within the Solution to identify Authorization, Audit, and Asset Protection needs.

Capturing this information prior to the start of each Phase makes subsequent design and delivery work as productive as possible.

To be sure, beginning with a holistic view of Security facilitates better segmentation of Solution Delivery work. Additionally, it allows for improved management of scope and risk, as well as clearer communication of work efforts. Moreover, it also facilitates reuse and consistency among Security components. As a result, it reduces the time and effort required to design & deliver individual Security objectives, while also improving their quality.

Objective

The goal of this artifact is to identify Security objectives, and to explain aspects common to each as they apply to the Solution. Furthermore, it explains how to apply guidelines described in the Security Strategy to best suit the Solution's needs. Moreover, it also provides specific orientation on the design, build and use of Security which everyone involved in those activities should follow. Accordingly, individual Security objectives need only reference most content included herein, rather than copying and including them within each Feature. Whereas individual Features describe items specific and unique the given Security objective, this Approach covers topics that should be consistent across several (or most) Security objectives, and hence redundant if left to the individual Features.

Audience

This audience for the Approach includes Solution Managers Architects, Business / Process Owners, Team(s) and DevSecOps members who will design and build the actual Integrations. In general, this Approach enables stakeholders to make initial estimates of security-related work. As a result, they are better positioned to manage expectations and organize delivery Teams. For instance, a Solution with many Security objectives might benefit by having one or more Teams dedicated to Security design and development. Conversely, a Solution with few Security objectives may find it easier to have Teams which focus upon specific functional areas, to also deal with any related Security. Another common, and recommended, alternative is to place all Security aspects with the DevSecOps group responsible for its long-term management. Regardless of the work division, anyone planning, designing and developing Security objectives will find this Approach offers them a valuable head start.

Sections Overview

To compile this Approach, begin with the Process Definition(s) which the Solution supports. Within each, identify Application Functionality and Data Objects and determine whether there is, or is not, a desire to secure access. Thereafter, complete the tables within this Approach for each object which requires Security.

Revisit the tables in this Approach prior to beginning each new Solution Phase.

This Approach seeks to summarize Security-related information by:

Identifying affected Business Process(es) or Technology Enabler(s) as well as their corresponding Functionality and Data Stores, identifying those which will - and which will not - require Security objectives.
Compiling suitable information for budgeting, resource planning and other high-level estimation of Security needs.
Identifying individual Security Objectives the Solution may require; and
Defining which Security Objective(s) to deliver during each Solution Phase.

Section 1 - Business Impacts

This Approach begins by describing the Business Process(es) or Technology Enabler(s), as appropriate, along with related Functionality and/or Data Objects within the Solution's Future- or End-State.

Processes / Enablers

Table SA5.1 lists the Business Process(es) or Technology Enabler(s) which the Solution supports. This table reflects information captured by Level 3 Diagrams for each Process. To compile this information, conduct a quick review of the completed Task Flow diagrams for each Process.

All Processes / Enablers listed in the 'Future State' section of the Application Strategy should appear in this table. As a result, Table SA5.1 will make it clear to everyone where to expect Security, and where not. In other words, this table helps define both what is, and what is not, in scope.

For each Process (or Enabler), the table identifies relevant User Groups and Data Objects, along with the assessment as to whether each will, or will not, require one or more Security objectives. User Groups and Data Objects affected by Security are given a short, unique title to identify the Security objective(s) required.

Table Values to Compile

The table which compiles Process or Enabler information lists the following:

Defined Business Process / Technology Enabler: Name of the Process or Enabler to which Functionality and/or Data Object(s) relate.
Related User Group(s) - without Security: A bulleted list of User Groups which relate to the given Process or Enabler, for which to expect no incremental Security objective(s). User Groups are a combination of Organizational Unit + Role. A single User Group may include multiple Org Unit + Role combinations.
Related User Group(s) - with Security: A bulleted list of User Groups related to the given Process / Enabler, for which to expect Security objective(s).
Related Data Objects - without Security: A bulleted list of Data Objects which relate to the given Process or Enabler, for which to expect no incremental Security objective(s).
Related Data Objects - with Security: A bulleted list of Data Objects related to the given Process / Enabler, for which to expect Security objective(s).
Security Title: Simple, unique identifiers of each Security objective. Each row may include multiple objectives.
Notes: After identifying a Security objective, use this field to capture any early information. Afterwards, once the corresponding Feature appears in the Solution Backlog, copy or move such information to the Feature's content.

Table SA5.1: Business Processes (or Technology Enablers) and Related Orgs, Roles & Data Objects

Defined Business Process	Related User Group(s) - without Security	Related User Group(s) - with Security	Related Data Object(s) - without Security	Related Data Object(s) - with Security	Security Title(s)	Notes

User Groups & Functionality

Table SA5.2 identifies the Solution User Group(s) affected by Security within the Solution. Give each Process / Enabler for which at least one Security objective is expected its own table. Accordingly, create a header for each table which includes 'for [Process Name]' or 'for [Enabler Name]'.

Relating Process / Enabler to Security helps provide context. For instance, the summary each table provides is helpful in determining which Security objective(s) to include within scope of a given Phase. If a goal in a Phase is to enable a certain Process, then including related Security is likely warranted. Moreover, this relationship also helps identify stakeholders to participate in subsequent Feature Planning

In time, each individual Security objective becomes a Feature to add to the Solution Backlog. When adding each Feature to the Work Management System (WMS) it will be given a unique ID. Accordingly, Security Title appears in the table instead. However, Table(s) SA2.2 is not the list of Security objectives. That is, the same Title may appear multiple times. Basically, this is because a given Security objective may address multiple User Groups and/or Data Objects / Stores. Conversely, multiple Security objectives may affect a given User Group and/or Data Object / Store. Accordingly, look to the Security Summary section later in this Approach for a list of Security objectives.

Table Values to Compile

For each Process or Enabler, the table which compiles User Security objectives lists the following:

Process / Enabler User Group: From Table SA5.1 above, the label given to each User Group.
Solution Function(s): Lists application or technology functionality (navigation menu items) to which the User Group should have access. Note that a given User Group may affect multiple Org Unit + Role combinations, or vice versa.
Authorization: A Y/N (actually, Y or blank) indicator of whether the Security objective relates to Authorization.
Audit: A Y/N indicator of whether the Security objective relates to Audit.
Asset Protection: A Y/N indicator of whether the Security objective relates to Asset Protection.
High-Level Security Description: A brief description of the desired Security.
Related Process(es) / Enabler(s): This provides a cross-reference because the same User Group may relate to multiple Processes / Enablers. This field lists each of the other Processes / Enablers from Table SA5.1 to which the User Group relates.
Security Title: Again, from Table SA5.1, the unique title representing a specific Security objective. Since a User Group may relate to multiple Security objectives, list each here.

Table SA5.2: Affected User Groups for [Process Name] [or Enabler]

Process User Group	Functionality	Authorization	Audit	Asset Protection	High-Level Security Description	Related Process(es)	Security Title

Data Objects & Stores

Table SA5.3 identifies the Solution Data Store(s) affected by Security objectives. Give each Process / Enabler for which at least one Security objective is expected its own table. Accordingly, create a header for each table which includes 'for [Process Name]' or 'for [Enabler Name]'.

Relating Process / Enabler to Security helps provide context. For instance, the summary each table provides is helpful in determining which Security objective(s) to include within scope of a given Phase. If the objective of a Phase is to enable a certain Process, then including related Security is likely warranted. Moreover, this relationship also helps identify stakeholders to participate in subsequent Feature Planning.

In time, each individual Security objective becomes a Feature to add to the Solution Backlog. At this point, the Security Title identifies each potential Feature. Although, Table(s) SA5.3 is not the list of Security objectives. That is, the same ID may appear multiple times. Basically, this is because a given Security objective may affect multiple User Groups, as well as Data Objects / Stores. Conversely, multiple Security objectives may affect a given User Community and/or Data Object / Store. Accordingly, look to the 'Security Summary' section later in this Approach for a list of Security objectives.

Table Values to Compile

For each Process or Enabler, the table which compiles Data Security objectives lists the following:

Process / Enabler Data Object: From Table SA5.1 above, the label given to each Data Object.
Solution Data Store(s): Lists application or technology Data Store (file, table, entity, etc.) which correspond to the Data Object. Note that a given User Group may affect multiple Org Unit + Role combinations, or vice versa.
Authorization: A Y/N (actually, Y or blank) indicator of whether the Security objective relates to Authorization.
Audit: A Y/N indicator of whether the Security objective relates to Audit.
Asset Protection: A Y/N indicator of whether the Security objective relates to Asset Protection.
High-Level Security Description: A brief description of the desired Security.
Related Process(es) / Enabler(s): This provides a cross-reference because the same User Group may relate to multiple Processes / Enablers. This field lists each of the other Processes / Enablers from Table SA5.1 to which the User Group relates.
Security Title: Again, from Table SA5.1, the unique title representing a specific Security objective. Since a User Group may relate to multiple Security objectives, list each here.

Table SA5.3: Affected Data Objects for [Process Name] [or Enabler]

Process Data Object	Solution Data Store	Authorization	Audit	Asset Protection	High-Level Security Description	Related Process(es)	Security Title

Section 2 - Security Common Functions

This section of the Security Approach describes functionality common across many, or all, Security objectives. Depending upon which Security aspects to implement, and the Design Patterns which correspond to each, there may be opportunities to establish Common Functions which individual

However, unlike the Integration Approach or Data Migration Approach, whether Common Functions can apply to Security is largely dependent upon the specific Tools in use. For those which Common Functions can help, this is the place to capture them.

Section 3 - Security Summary

Compiling information form the tables above, this section summarizes all Security objectives for the Solution. Moreover, it offers an opportunity to arrange multiple objectives by the Solution Evolution Phase during which to expect delivery.

Use Table SA5.4 to help estimate resources - staffing, funding, etc. - as well as timing applicable to Security. However, for actual Phase-by-Phase timing, refer to the section 'Approach per Solution Evolution Phase' later on in this artifact. Similarly, for additional information on the Processes to implement in any given Phase, refer to the Application Strategy.

Backlog Security Features

If not already done, then now is the time to add Features to the Solution Backlog. To be clear, each proposed Security objective should have its own, corresponding Feature. When adding each Feature to the Work Management System (WMS) it will be given a unique ID. This ID is also known as the WMS Feature Key.

Ensure the Feature Name, and/or Feature Summary is the same as the Security Title which appears in the tables of this Approach. Additionally, add the High-level Security Description from Tables SA5.2 and SA5.3 to the Feature Description. If applicable, then also move Notes from Table SA5.1. Finally, associate each Security Feature with the Solution's Standard Epic for Operations. At this point, each Feature has sufficient information to remain in the backlog.

In time, Feature Planning will make each Feature "Ready" for subsequent implementation. Alternatively, for any proposed Security objective(s) never approved for delivery, the backlog Feature becomes the historical record, describing the relevant justification and decision maker(s).

Table Values to Compile

Table SA5.4 summarizes all of the Security objectives planned for the Solution. For each Security objective, list the following:

Process / Enabler: The Business Process or Technology Enabler which involves, or is directly related to, the given Security objective.
Security Title: A brief name for the Security objective.
Proposed Solution Phase: The suggested Solution Phase during which to expect initial delivery of the given objective.
WMS Feature Key: The ID or key from the Work Management System which identifies the specific Feature to enable the given Security objective.

Table SA5.4: [Solution ID / Name] - Proposed Security Objectives

Process Name	Security Title	Proposed Solution Phase	WMS Feature Key

Section 4 - Approach per Solution Evolution Phase

The final section of this Approach defines which Security objectives to expect during each Solution Phase. Previously, Table SA5.4 - Security Summary offered opportunities to review and organize the entire list of proposed Security objectives for resource planning purposes.

Security Objectives by Solution Phase

At this point, tables in this section capture decisions that result from those earlier estimates and related resource planning. As a result, they also tie to the Solution Roadmap. Moreover, rows in each table align individual Security objectives with the overall Security Strategy.

Table Values to Compile

The header for each Table is 'Phase [Phase ID]: [Phase Name] - Security'. For each Phase, the values to compile in each table include:

Phase ID / Name: From the Application Strategy, the Solution Phase during which to expect the Integration's initial delivery.
Security Title: The Feature Name (or Feature Summary) for the specific Security objective.
Security Description: A copy of, or comparable to, the Security objective's initial Feature Description.
Authorization: A Y/N (really, Y or blank) indicator of whether the objective relates to Authorization.
Audit: A Y/N indicator of whether the objective relates to Audit.
Asset Protection: A Y/N indicator of whether the objective relates to Asset Protection.
Design Pattern: From the Security Strategy, the pattern which the Security objective is to apply.
WMS Feature Key: The ID, or key, in the Work Management System which uniquely identifies the Security objective in the Solution Backlog.

Table SA5.5: [Solution ID / Name] - Proposed Security Objectives

Phase ID / Name	Security Title	Security Description	Authorization	Audit	Asset Protection	Design Pattern	WMS Feature Key

End Template /

Optionally, include the following Checks & Balances.

Checks & Balances - Alignment to Other ITM Artifacts

This section is available in many Solution Strategy & Architecture artifacts, to help those who create, and use, this information see the "bigger picture".

Checks & Balances highlight where similar information appears in multiple locations. The reason to display info more than once is to help ensure alignment and consistency across all stakeholders. Each appearance offers a different perspective for a different audience. The more widely available such information becomes, the more likely it is to drive common understanding. As a result, this helps initiatives to progress more quickly and with fewer impediments.

Section 1 - Business Impacts

In short, Section 1 offers a high-level overview of the Processes or Enablers, depending upon Solution Type, and Data Objects which Security may affect. Accordingly, it extends and highlights information relevant to those orchestrating implementation.

Table SA5.1

Business Processes (or Technology Enablers) appearing in Table SA5.1 must also exist in the Application Strategy Table SS1.2: Future State Processes & Supporting Components. Unless the Process (or Enabler) appears in Table SS1.2, it is not yet approved for this Solution. Hence, no work should occur related to it. Furthermore, each Process should also appear in the corresponding Solution Context Diagram. For additional information on why the Security objective exists, or where in the sequence of events it occurs, look to the corresponding Process Definition.

Similarly, each Data Object appearing in Table SA5.1 must also exist in the Application Approach Table SA1.2: Major Solution Data Objects. Specifically, Data Objects which appear in the With Security column may appear either the In-Scope or Future-Scope columns of that table. Otherwise, Data Objects which appear in the Without Security column may appear in the In-Scope, Future-Scope, or Out-of-Scope columns of Table SA1.2.

Table SA5.2

Any User Group, Authorization, Audit, and Asset Protection values which appear in Table(s) SA5.2 do not appear in any other Solution Strategy & Architecture artifact. Rather, these values help identify and organize individual Security Objectives.

Although, any Functionality value which appears in this table must also appear in Table SA1.1: Major Solution Functions of the Application Approach. Specifically, it should appear in the In-Scope or Future-Scope columns. Any Functionality listed in the Out-of-Scope column should not appear in this table.

As above, any Related Process(es) should appear in Table SS1.2: Future State Processes & Supporting Components of the Application Strategy. Again, if a process does not appear in that table, then no further work should reference or relate to it.

Finally, the Security Title should be consistent across all tables in this Approach in which this value appears. Moreover, it should also be consistent with the Feature Title in the Solution Backlog which corresponds to the specific Security objective.

Table SA5.3

Any Authorization, Audit, and Asset Protection values which appear in Table(s) SA5.2 do not appear in any other Solution Strategy & Architecture artifact. As above, they help identify and organize Security Objectives.

Although, any Data Object which appears in this table must also appear in Table SA1.2: Major Solution Data Objects of the Application Approach. Specifically, it should appear in the In-Scope or Future-Scope columns. Any Data Object listed in the Out-of-Scope column should not appear in this table.

A Solution Data Store listed in the table should correspond to descriptions which appear in vendor documentation or other, similar materials. In most cases, Data Stores should also appear in the Process Diagrams and Matrices.

As above, any Related Process(es) should appear in Table SS5.1. Ideally, they are Defined Processes and hence have Process Definition artifacts associated with them. However, some Processes may also be undefined. If so, they will lack corresponding diagram and matrix details.

As before, the Security Title should be consistent across all tables in this Approach in which this value appears. Moreover, it should also be consistent with the Feature Title in the Solution Backlog which corresponds to the specific Security objective.

Section 2 - Security Common Functions

Any content added to this section may or may not relate to other artifacts. If the content does make any reference(s) to other ITM artifacts, then add them here.

Section 3 - Security Summary

This section summarizes all potential Security objectives. However, the appearance of a Security objective in this section does not guarantee it will ever be implemented.

Table SA5.4

Each Process Name appearing in Table SA5.4 must correspond to one listed in Table SA5.1. Likewise, the Security Title should also correspond to a value which appearing in that table.

The Proposed Solution Phase must correspond to one previously described in Section 2 of the Application Strategy, as well as Table(s) SS1.4: Solution Phase - SID-PHnn: [Phase Name]. Similarly, the WMS Feature Key must correspond to the Feature ID as it appears in the Solution Backlog.

Section 4 - Approach per Solution Evolution Phase

To conclude, this section prioritizes individual Security objectives into the Solution Phase during which to expect delivery of the corresponding Feature.

Table SA5.5

Firstly, the Phase ID / Name of Table SA5.5 must correspond to one described in Section 2 of the Application Strategy. Secondly, the Security Title must correspond to the same value which appears in Table SA5.1 as well as Table SA5.2 or Table SA5.3.

Thirdly, Each Security Description should match a description appearing in Table SA5.2 or Table SA5.3, depending on whether the objective relates to a User Group or Data Object. Likewise, the Security aspect - Authorization, Audit, or Asset Protection - should align with the Table SA5.2 or Table SA5.3 indicator(s).

Fourthly, the Design Pattern must correspond to one which appears in Table SS5.1: Security Scenarios & Design Patterns of the Security Strategy. Finally, the WMS Feature Key must correspond to a value which appears in Table SA5.4 above.

How to Develop a Security Approach

In most cases, a Solution Architect or Application / Technology Architect facilitates the creation or update of this Approach. However, they should do so in collaboration with affected Epic Owners as well as relevant Business / Process Owners. Additionally, they will require input from Subject Matter Experts familiar with regulatory requirements.

To create the initial version, use the preceding template content on this page. Otherwise, to update this Approach for a subsequent Phase, use the most recent version from a preceding Phase. Thereafter, follow the steps below to create, or update a Solution's Security Approach.

Regardless of which Phase the artifact is for, completion of the current version occurs during Phase Inception. At that time, long-term scope of the Phase, including which Security objectives to deliver, is set. As a result, the finalized Approach per Solution Evolution Phase section defines the scope of Security for the next Phase.

Section 1 - Business Impacts

To start this Approach, describe how potential Security objectives relate to the individual Process(es) or Enabler(s) the Solution supports. Accordingly, complete Steps 1, 2 and 3 to describe the Business Impacts of Security.

Step 1: Determine Affected User Groups & Data Objects - Create / Update Table SA5.1

To begin providing Solution-specific content to the template artifact, list each Process or Enabler as they appear in Table(s) SS1.4 of the Application Strategy. At a minimum, list the Future-State Process(es) which apply to the pending Solution Phase. Alternatively, list all Processes, regardless of Phase. The latter helps identify multiple Processes which may affect one another.

For each Process added to the table, review the corresponding Task Flows (Level 3 Diagrams). In short, parse through the diagrams, or corresponding Process Detailing Matrix, to identify referenced Roles and corresponding Organizational Units, as well as Data Objects. Of course, these lists can begin prior to the Level 3 flows being complete. However, lists cannot be final until sign-off of Level 3 diagrams occurs for each Process.

User Groups are formed by a combination of Organization Unit (Org Unit) + Role(s). For example, Finance (Org Unit) members fulfilling Payables Clerk (Role) positions may be a User Group. In general, User Groups tend not to cross Org Unit boundaries. However, they may contain more than a single Role. Regardless, each User Group must contain at least one Org Unit + Role combination but may include multiple combinations.

Applicable Process Security

For each User Group, determine whether there is a desire to apply any type of Security, beyond Authentication, to Users within the group. Similarly, for each Data Object determine whether there is a desire to provide any type of Security to the data which the object represents,

List all User Groups and Data Objects for the Process in either the 'with' or 'without' Security columns of the table. In general, a User Group or Data Object should appear in either the 'with' or 'without' column for a given Process. Although, it is possible for a User Group or Data Object to appear in both columns, though for different Processes.

To clarify, put User Group or Data Objects in the 'with' column only when the items to secure relate directly to execution of the corresponding Process. Finally, identify individual Security objectives by giving each a unique Security Title. Optionally, add any information relevant to understanding, assessing or prioritizing individual Integrations using the space for Notes.

Step 2: Identify Relevant Security Objectives - Create / Update Table(s) SA5.2

Previously, Table SA5.1 identified all User Groups associated with each Business Process. Furthermore, it identified which related User Groups may require some type of Security. At this point, Table(s) SA5.2 highlights Security objectives as they relate to each Process. This is to help align potential Security work with other Process-related efforts as defined in the Application Approach.

To begin, look to each row in Table SA5.1 which identifies one or more User Groups in the 'with Security' column. For each corresponding Process, create a Table SA5.2, giving each header a unique, one-letter identifier, such as Table SA5.2a, Table SA5.2b, Table, SA5.2c, and so on. Be sure to include the Process Name in each header.

Secondly, for each Process, add a row to the table for each 'with Security' User Group, and list the group in the first column. Thereafter, identify the application or technology Functionality to which the given User Group should (or should not) have access. For most Solutions, this involves listing values from the Solution's navigation menu. Moreover, this may involve more than one menu value or function.

User Group Security Objectives

Thirdly, identify desired Security aspects as Section 1 of the Security Strategy describes. At this point, Authentication is assumed as it typically applies to all functionality equally. However, identify Authorization, Audit, and Asset Protection objectives individually. Indeed, create a separate row for each. For instance, if some Functionality for some User Group requires Authorization, Audit, and Asset Protection, create a row for each.

Fourthly, provide a brief description of the proposed Security objective. In short, this is a quick what, when, and why to support the case for spending time and money on a potential Security objective. Descriptions should involve no more than one means by which to implement the Security objective. That is, if Security for a User Group requires multiple, different Design Patterns to implement, then each objective gets its own High-level Security Description.

Fifthly, look back to the 'without Security' column in Table SA5.1. If the User Group referenced by the current row of Table SA5.2 appears in that column for any other Process, list the Process Name(s) as Related Process(es). Finally, copy the corresponding Security Title from Table SA5.1. Alternatively, add a new Title here and make corresponding updates to Table SA5.1.

Step 3: Identify Additional Security Objectives - Create / Update Table(s) SA5.3

Previously, Table SA5.1 identified all Data Objects associated with each, relevant Business Process. Furthermore, it identified which related Data Objects may require some type of Security. At this point, Table(s) SA5.3 highlight additional Security objectives as they relate to an individual Process. As above, this is to help align potential Security work with other Process-related efforts as defined in the Application Approach.

To begin, look to each row in Table SA5.1 which identifies one or more Data Objects in the 'with Security' column. For each corresponding Process, create a Table SA5.3, giving each header a unique, one-letter identifier, such a Table SA5.3a, Table SA5.3b, Table, SA5.3c, and so on. Be sure to include the Process Name in each header.

Secondly, for each Process, add a row to the table for each 'with Security' Data Object, and list the object in the first column. Thereafter, identify the file / table name(s) within the Solution which store values for the given Data Object. For some Solutions, this may involve more than one Data Store. However, in most cases, there should be a relatively obvious 'main' file or table.

Data Object Security Objectives

Thirdly, identify desired Security aspects for each Data Object. That is, identify whether there is a desire to apply Authorization, Audit and/or Asset Protection to the object. Doing so provides means to cross-check Security aspects from Table SA5.2. As before, if some Data Object requires Authorization, Audit and Asset Protection, then create a row in Table SA5.3 for each.

Fourthly, provide a brief description of the proposed Security objective. In short, this is a quick what, when and why to support the case for spending time and money on a potential Security objective. Descriptions should involve no more than one means by which to implement the Security. That is if Security for a Data Object requires multiple, different Design Patterns to implement, then each objective gets its own High-level Security Description.

Fifthly, look back to the 'without Security' column in Table SA5.1. If the Data Object referenced by the current row of Table SA5.3 appears in that column for any other Process, list the Process Name(s) as Related Process(es). Finally, copy the corresponding Security Title from Table SA5.1. Alternatively, add a new Title here and make corresponding updates to Table SA5.1.

Quick Validations

At this point, conduct a few validations. Firstly, verify that the same User Group does not appear in more than one SA5.2 table. Similarly, the same Data Object does not appear in more than one SA2.3 table. If one does, then take a closer look at it. Perhaps additional detail is required to differentiate two seemingly similar Security objectives.

In some cases, a Security objective for Process A might address access to functions 1 & 2. Alternatively, Process B requires functions 2, 3 & 4. As above, the proper approach is to segment the different needs into separate, distinct Security objectives. Later, discussions and decisions determine whether to tackle multiple, related objectives at one time, or to build one first and extend it later.

Clarify Security Objectives

For the second validation, verify that each High-level Security Description references only a single Security aspect - Authorization, Audit, or Asset Protection. If any description references multiple related Design Patterns, then create a copy of the description for each type.

Afterwards, verify that each row in Tables SA5.2 and SA5.3 include just one High-level Description. If a row contains multiple descriptions, then create a row for each. Repeat the User Group and Functionality values (SA5.2) or Data Object and Data Store values (SA5.3) for each. Additionally, update any Security Title value(s) as appropriate.

If restating initial User Groups or Data Objects occurs, either by segmenting into more detail, or aggregating into less, then make similar changes to Table SA5.1. Moreover, ensure similar changes occur to the corresponding Process Definition flow diagrams and matrices. Maintaining consistent information across artifacts is vital to ensure clear communications and manage expectations.

Validations are done when the same User Group does not appear in more than one SA5.2 table, and each User Group does not have more than a single High-level Security Description. Additionally, the same Data Object does not appear in more than one SA5.3 table, and each Data Object does not have more than a single High-level Security Description.

Section 2 - Security Common Functions

For the most part, this section merely offers guidance for each Security objective to follow. There is no need to complete any table in this section.

Step 4: Define Common Functions

However, while there is no need to update any table, there are opportunities to do so. Capturing or updating Common Functions before each Solution Phase can offer a head start to the delivery of any Security objective during subsequent Phases.

For instance, Common Functions help guide standardization and consistency across multiple Security objectives. As a result, this often leads to faster delivery times, improved re-use of previously delivered items, and higher quality implementation.

In another example, as Teams make design and delivery decisions, capture relevant outcomes for the benefit of subsequent Security objectives. Thereafter, those outcomes now guide any subsequent, similar objective(s).

Indeed, the capture of any 'lessons learned' which can help speed delivery, increase consistency and minimize problems is always a step in the right direction.

Section 3 - Security Summary

At this point, it is time to use the information compiled in the preceding tables to roughly estimate the timing and sequencing of Security implementation.

Step 5: Summarize Proposed Security - Create / Update Table SA5.4

To begin Table SA5.4, look back to Tables SA5.1, SA5.2, and SA5.3 for the list of Security Titles. Add each, unique value to this table's Security Title column.

Afterwards, for each row in Table SA5.4 with a Security Title, look back to Table SA2.1. Find the Security Title in that table and identify the corresponding Process (or Enabler) for which a User Group or Data Object appears in the 'with Security' column of Table SA5.1. Add the Defined Business Process value to Table SA5.4.

Thirdly, identify a Solution Phase for which to recommend initial delivery of each Security objective. Look to Application Approach for the Process(es) defined as being in scope for each Phase. If an objective has already been achieved during a prior Phase, then state the actual Phase instead of a proposed one.

Security Timing

Some will argue that it is easiest to defer Security implementation until other implementation tasks, such as development and testing, are complete. This is not a great idea. Of course, doing so allows developers and testers to simplify their work. However, it also means foregoing many opportunities to validate a vital aspect of any implementation. Accordingly, it is best to propose Security delivery in the following order:

In Development Environments, it is fine to forego Security configuration. Although, if any exists that is generally a plus.
In most Test Environments, it is fine to implement some basic, generic Security. For instance, configure a few sample Authorizations, Audits, and/or Asset Protections as appropriate for the Solution. While there is no need for all Security configurations, there must be enough to provide suitable 'proof of concept' for each Design Pattern.
By the time System Testing begins, typically in a QA Environment, all Security configurations must be in place. As a result, all testing occurs within a 'production-like' Environment. There is no point executing System Tests or User Acceptance Tests without applicable Security in place.
A Production Environment requires the fully configured, and fully tested, Security configurations for each Security objective.

Since Security is often contained within Environments, it is often brought along when one Environment is copied into another. Accordingly, ensure an appropriate level of Security configuration exists in the source Environment(s). Thereafter, add new, incremental Security configurations that carry forward into subsequent Releases. Refer to the Operations Approach for more on Environments and their use.

Basically, schedule Security objectives in the same Phase as corresponding Process implementation. However, in doing so, Roadmap Planning must consider Feature sequencing. That is, Security objectives should occur in parallel with, or immediately after, any change which relates to the corresponding Functionality or Data Object. The should not be left until 'sometime later'.

Finally, once a Security objective has a Feature in the Solution Backlog, identify that Feature in the WMS Feature Key field. As a result, anyone viewing this Approach could seek additional information.

Section 4 - Approach per Solution Evolution Phase

Complete this final section of the Approach during Phase Inception, when the juggling of what's in, what's out, and what's next occurs. Of course, a preliminary draft, or recommendation, of the Security objective(s) to include in any Phase is helpful.

However, finalizing a list of Security objectives for a Phase depends upon decisions made for other Approach artifacts, such as the Application Approach. Moreover, it also depends on practical considerations, such as resource constraints. As a result, finalizing all such items is an output of each Phase's Inception.

Step 6: Define Approach for Phase - Create / Update Table(s) SA5.5

To begin, look to Section 2 in the Application Strategy for the current list of Solution Evolution Phases. For each Phase, create a Table SA5.5. Give each header a unique, one-letter identifier, such as Table SA5.5a, Table SA5.5b, Table, SA5.5c, and so on. Be sure to include the Solution Phase ID / Name in each header.

Afterwards, add the given Phase ID / Name to the first column of each Table SA5.5. This is helpful when extracting specific rows for use outside of this Approach.

Secondly, during discussions and negotiations which occur during Phase Inception, define the list of Security objectives to deliver during the pending Phase. For each objective in-scope for the Phase, add the Security Title to an appropriate row in Table SA5.5.

Thirdly, look back to the prior tables in this artifact, and copy the relevant information to the Security Description, Authorization, Audit, and Asset Protection columns.

Fourthly, look to the Security Strategy. If there is a recommended, or preferred Security Scenario for a given objective, then identify the corresponding Design Pattern which the Security objective should apply.

Finally, if any Security objective does not yet have an existing Feature to represent it in the Solution Backlog, then add one now. After adding the Feature(s), record their Feature Key in this table. This will direct anyone seeking additional information to the correct backlog objects.