We strive to focus on architectures, methodologies, best practices and the latest technologies designed for proactive strategies that can be used for reducing the IT security risks and meeting the new security challenges. Well, I decided to write this blog inspired by Gartner's information security model.
Infrastructure Protection
The technology infrastructure is a fundamental to security and it must be fundamentally secure. Enterprises must prevent and limit damage to their business operations by deploying policies, processes, and technologies to detect and block attacks – both internal and external. We endeavour to minimize the vulnerabilities that enable attacks. The enterprise threat environment is changing rapidly, as are the approaches, applications, and technologies enterprises use to engage customers and partners. Therefore, the strategies must change with them. I believe the right approach is to focus on the processes, technologies, and services needed to protect data, applications, systems and the network, as well as to discover new ways and solve the security weaknesses.
The technology infrastructure is a fundamental to security and it must be fundamentally secure. Enterprises must prevent and limit damage to their business operations by deploying policies, processes, and technologies to detect and block attacks – both internal and external. We endeavour to minimize the vulnerabilities that enable attacks. The enterprise threat environment is changing rapidly, as are the approaches, applications, and technologies enterprises use to engage customers and partners. Therefore, the strategies must change with them. I believe the right approach is to focus on the processes, technologies, and services needed to protect data, applications, systems and the network, as well as to discover new ways and solve the security weaknesses.
Secure Business Arena
Once a security is built, it must be provided with a secure environment around by knowing how to trust users, consumers, and partners. Past approaches no longer fully address organizational demand for a well-managed and automated identity and access management function. Legacy access control technologies, fragmented user administration products are all typical examples of business ‘disabling’ approaches that are no longer sufficient. New techniques and tools are needed to manage the identities and entitlements of end users inside and outside the organization, and provide assurance against fraud, deception, and identity theft. For this we focus on process and technologies that integrate security into electronic business processes and transactions.
Risk Management and Compliance
Compliance and risk management are not about technology. However, the fact is this: IT systems support the way an organization lives and breathes. It would be difficult to help business units within the organization, understand, and manage IT related risks and achieve compliance confidently. Except, by systematically addressing IT risks across the enterprise and improve critical business and security management processes. Such a proactive approach will enable top line growth while maintaining necessary levels of control in the complex areas of governance, regulations, risks, performance, sourcing, security, and access control and vendor selection. To address this we focus on the tools, strategies, and tactics characteristic of a coordinated program for addressing regulatory, commercial, and organizational risk effectively.
What We Need To Know
Enterprise architecture (EA) framework should allow for security-related requirements and artifacts to be organized within primary EA viewpoints, but should also have these security elements abstracted to a security- only viewpoint. This allows different stakeholders to view these requirements and artifacts in ways that best help them do their jobs while ensuring that security requirements are built in to all aspects of solutions.
Enterprise architecture (EA) framework should allow for security-related requirements and artifacts to be organized within primary EA viewpoints, but should also have these security elements abstracted to a security- only viewpoint. This allows different stakeholders to view these requirements and artifacts in ways that best help them do their jobs while ensuring that security requirements are built in to all aspects of solutions.
Architecture Analysis
An architecture framework provides a structure and a common set of semantics that enforce consistency across the wide range of participants in enterprise architecture initiatives who typically come from diverse areas of the business. Without a framework, it is difficult to relate work in different areas to each other and to integrate that work. With a framework, work in different areas by different constituencies can be better related and thus optimized to eliminate overlaps and contradictory guidance as well as to define gaps that are otherwise not getting planned at all.
Viewing relevant portions of a collection of artifacts from the viewpoints of various stakeholders — such as the viewpoint of the security professional — should also be easy. By using an EA framework, EA and other non- security constituencies in IT and the business can better see the value of security planning. Likewise, security planners can better see the work of non-security constituencies and can better understand how to support those efforts.
In "Incorporating Security into the EA Process" we describe how to ensure that security and privacy requirements are holistically incorporated into the enterprise architecture development, management, and governance processes. Ultimately, this ensures that business solutions have security and privacy controls "baked in," and that these controls are commensurate with enterprise business needs and risks. This organizational and process work is ultimately more important than how to organize security artifacts in an EA framework.
Nevertheless, when architects and security professionals work through these processes, they can create a broad set of artifacts that provide the records of the process work and help guide future desirable solutions, behaviors and controls. These artifacts must be organized in ways that can be easily used and viewed by all stakeholders. Security planning must not be isolated, and the artifacts of that planning must not be completely divorced from all other planning documents. At the least, a single repository should house all EA documentation for future state guidance.
From our client interactions, we see three common approaches to developing security architecture in the context of EA frameworks. Choosing any of these approaches does not arbitrarily limit the real security work that is done. However, each approach has pros and cons in terms of how easily the security work is exposed to the EA's different stakeholders — its users.
Security as a Domain in Technology Architecture Approach
Security is represented as a domain in enterprise technical architectures with security standards, technologies and products being documented by functional category — for example, virus prevention, intrusion prevention and firewalls. This approach addresses security in the technology context only and does not support integration of security requirements into business solutions from inception. Nor does it allow for the development of security process or other guidance by security professionals. Information security issues, including the typing of information as to its privacy and risk aspects, are clearly an information architecture issue, and would be hard to fit into a technology-only view. Nevertheless, this is a way to start planning security in an EA framework context. This area's level of guidance is certainly required (for example, defining security product standards for firewalls, developing plans for shared security infrastructure to reuse across applications and projects, such as firewalls and identity infrastructure). This approach is best used when the accountability and responsibility for EA development are with the IT operations organizations, and when technical architecture is the only viewpoint being developed.
An Integrated Security Approach
A second option is to view security as a complete viewpoint with its own models to be integrated into solutions but separate from the business process, information and technology viewpoints. Figure 1 shows the security-only viewpoint in context with these other viewpoints.
This approach has the advantage of letting security people have their own view. However, if the security viewpoint is the only way these artifacts are stored and viewed, this could create a new holistic set of EA-like security-specific structures (that is, business processes, information, technology, and solutions) that mimics the same structures of the entire EA. If this is the only way security-related artifacts are organized and retrieved in the repository, then this method may lead to more overlaps and possibly gaps than if security were more pervasive in EA's view of all plans, rather than walled off from it. However, most organizations do not have the work and planning processes of the security organization integrated with the work and planning processes of the EA team.
This approach of a separate security viewpoint in the EA framework is useful when initially joining the work of the two groups. Another potential problem exacerbated by relying on a security-only view relates to isolated planning for components and services that mix security and non-security elements. These components and services can't be planned only by security people. You may need to plan an identity management service, yet the underpinning directory service may already have been planned by other IT constituencies (that is, networking, database, and so on). Will security now plan this again in overlap of other constituencies? Also, who plans the remote access service — security or networking people? The answer is both, so this security-only view would likely generate only a second possible remote access design not in concert with networking. Ultimately, planning this way will take longer and will not produce the high quality of doing things in a more unified way.
Of course, this overlap can also be reduced by a planning process that caters to cooperation. Integrating the architecture reinforces better collaboration, but is not a prerequisite for better collaboration. Many of the artifacts listed in this figure include those that would be created by the information security organization when developing separate enterprise information security architecture (EISA) in isolation from the EA work.
This approach of a separate security viewpoint in the EA framework is useful when initially joining the work of the two groups. Another potential problem exacerbated by relying on a security-only view relates to isolated planning for components and services that mix security and non-security elements. These components and services can't be planned only by security people. You may need to plan an identity management service, yet the underpinning directory service may already have been planned by other IT constituencies (that is, networking, database, and so on). Will security now plan this again in overlap of other constituencies? Also, who plans the remote access service — security or networking people? The answer is both, so this security-only view would likely generate only a second possible remote access design not in concert with networking. Ultimately, planning this way will take longer and will not produce the high quality of doing things in a more unified way.
Of course, this overlap can also be reduced by a planning process that caters to cooperation. Integrating the architecture reinforces better collaboration, but is not a prerequisite for better collaboration. Many of the artifacts listed in this figure include those that would be created by the information security organization when developing separate enterprise information security architecture (EISA) in isolation from the EA work.
Conceptual
Environmental trends — Laws and regulations that require specific security and privacy practices and controls (such as HIPAA, SOX and so on)Business strategy — Business goals for the year, including changes to process that will involve external parties, in which security considerations may be paramount to success. Business relationships identified and described require secure data transfer between parties.
Requirements — given the business strategies (such as more involvement with external business partners), processes, information, technology, and related solution changes must be defined to guide change in security areas. For example, with the Health Insurance Portability and Accountability Act (HIPAA) regulations, many health care organizations must redefine business processes to include information confidentiality and would point to need for encryption over links to business partners (or authentication, even strong authentication).
Principle — Security requirements will be included with every business process model, information model and technical model (particularly patterns and services in all areas). Information must be treated as a business asset — with the implication that information must be properly secured to remain a business differentiator (otherwise, your competitor will know your customers).
Models — A health care conceptual business process model depicting patient information transfer between two health care providers and the associated security requirements for confidentiality and integrity. A security vision document, trust model definitions, security services model, security policy framework, and data classification framework.
Logical
A logical business model depicting each functional component in a health care patient data transfer business process including security functions
Trust Model
A logical technology pattern or model depicting end-point health care systems along with the network and security functional components (such as firewalls, intrusion protection system [IPS] and virus prevention)
Implementation
Implementation templates for an end-to-end solution, depicting specific health care system modules, firewall make and model, IPS, product, version and so on Documentation showing standard, retirement targets, and future emerging corporate standards for firewalls and IPS.
No comments:
Post a Comment