In an ideal world, management of Information Security would be predicated on providing Security Policy Definition and Security Administration for the corporation. Unfortunately, it is not an ideal world. Some firms are not even aware of the actual Security Policies that have been implemented. The logic associated with the security policies is often buried within software application code. As numerous software applications are deployed, Semantic mismatches and Metadata issues may frequently occur, especially when a Common Business Language does not exist.
Moreover, there is rarely a requirement for software application code to be rigorously documented. Hence, the following must occur to resolve these issues:
- The managers on the Data Governance Council must define the Security Policies by working with their Business Partners and deciphering Policy Artifacts.
- Application code must be reverse-engineered and documented to truly understand which policies are already in place.
- Any gaps that exist between a) and b) must be documented and addressed.
- A Common Business Language Taxonomy must be developed to articulate the rules and procedures associated with complying with the edicts provided by the Data Governance Council.
SECURITY POLICY DEFINITION
This phase of the Security Development Lifecycle addresses a corporation’s definition of the rules associated with grants, encryption requirements, authentication procedures, and temporal policies (i.e., archiving policies, temporary suspension of access rights (e.g., no updates of core data during month end closing, etc.)) and other enterprise-driven decisions. The Policy Definition phase is used to define the explicit Security Entitlement rules that should be applied to the Data Assets owned by a particular enterprise. The typical types of rules include:
- Role-Based Security Grants
- Authentication Rules
- Acceptable Usage of Information
- Individual Demographics
- Location-Driven Rules (e.g., Global ‘Localization’ Security Rules, as defined by a particular country, On-Site Rules, Remote-Access Rules)
- Temporal Considerations
- Server Identity Rules (note: this is important because the notion of ‘Trusted Sites’ allows an individual to identify sites that can communicate with enterprise servers without the usual Authentication Rules. This may enable hackers to impersonate one of the servers on the ‘Trusted Sites’ list).
SECURITY ADMINISTRATION
This phase of the Security Development Lifecycle is driven by the actual managerial topology associated with an enterprise’s landscape. The GITS Data Governance Handbook provides detailed steps to determine the managerial style associated with Data Governance. Some of the options are listed below:
CENTRALIZED
- Central Security Tsar (CST) Business Unit (BU) defines and manages Security Policy Rules for the entire enterprise
- CST has the option to deploy Regional Security Administrator BUs to manage the DBMS, Network (‘Implied’ Hub-and-Spoke model), and Application Security Entitlement Rules
DISTRIBUTED
- Each Regional geographical location has complete autonomy of the establishment of Security Entitlements
- A Core Corporate Security BU still exists, but it is passive – it only receives Security Entitlement Rules, and notifies management when rules are defined that are contrary to corporate policy
FEDERATED
- Based on melding Centralized and Distributed (Explicit Hub-and-Spoke model)
- Cross-Regional Handshakes must occur
GITS provides resources and training/training materials on how to capture Security Entitlements information in a Meta-Data Repository that can be used with ‘off the shelf’ tools (e.g., Tableau, Informatica, Microsoft Excel). The design of the Meta-Data repository is intuitive. We will work side by side with you to extend our repository design to uniquely accommodate your needs. At the close of our engagement, the knowledge-transfer process will be complete and the repository is yours to keep.
GITS has factored into our Meta-Data Repository design the fact that all Business Attributes are not on the same level or equal. You will encounter instances in which there is not a 1 to 1 relationship between what is implemented vs. what is stated in your narrative Security Policy Artifacts. This often occurs due to Semantic Inconsistencies – sometimes Business Attributes are used to derive other Business Attributes. Our Meta Data Repository addresses this issue.
What does it take to understand how the Security Policies have been defined and implemented in your environment? Does it require a person to review narrative security policies, which are often stored in multiple documents, and/or interview Software Developers and Data Base Administrators? If so, it would be a good idea to contact a GITS representative – our solution would provide you with the capability to execute a query to understand Security Entitlements in your environment.