Best IT Blog

Understanding Cloud Security Alliance – Cloud Security Domains

Posted in Security (1500),Virtual - VMWare (30),Visio Samples - Stencils (457) by Guest on the September 10th, 2017


Establish guidance, direction, advisement, reference architectures, ensures alignment to business requirements.



Governance and Enterprise Risk Management

The ability of an organization to govern and measure enterprise risk introduced by Cloud computing. Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a Cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues.


Legal issues; Contracts and Electronic Discovery

Potential legal issues when using Cloud computing. Issues touched on in this section include protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws etc…


Compliance and Audit Management

Maintaining and proving compliance when using Cloud computing. Issues dealing with evaluating how Cloud computing affects compliance with Internal Security Policies, as well as various compliance requirements (regulatory, legislative and otherwise) discussed here. This domain includes some direction on proving compliance during an audit.


Data Governance

Governing data that is placed in the Cloud, items surrounding the identification and control of data in the Cloud, as well as compensating controls that can be used to deal with loss of physical control when moving data to the cloud, are discussed here. Other items, such as who is responsible for data confidentiality, integrity, and availability are mentioned.




Manage Plan and Business Continuity

Securing the management plan and administrative interfaces used when accessing the Cloud, including both web consoles and API’s. Ensuring business continuity for Cloud deployments.


Infrastructure Security

Core Cloud infrastructure security, including networking, workload security and hybrid Cloud considerations. This domain also includes security fundamentals for private Clouds.


Virtualization and Containers

Security for hypervisors, containers and software defined networks.


Incident Response Notification and Remediation

Proper and adequate incident detection, response, notification and remediation. This attempts to address items that should be in place at both provider and user levels to enable proper incident handling and forensics. This domain will help you understand the complexities the Cloud brings to your current incident handling program.


Application Security

Securing application software that is running on or being developed in the cloud. This includes items such as whether it’s appropriate to migrate or design an application to run in the cloud, and if so, what type of Cloud platform is most appropriate (SaaS, PaaS, IaaS).


Data Security and Encryption

Implementing data security and encryption, and ensuring scalable key management.

Identity, entitlement, and Access Management

Managing identities and leveraging directory services to provide access control. The focus is on issues encountered when extending an organization identity into the Cloud. This section provides insight into assessing an organization’s readiness to conduct Cloud-based identity, entitlement, and Access Management (IDM).


Security as a Service

Providing third party facilitated security assurance, incident management, compliance attestation, and Identity and Access oversight.


Related Technologies

Established and emerging technologies with a close relationship to Cloud computing, including Big Data, Internet of things, and mobile computing.

Comments Off on Understanding Cloud Security Alliance – Cloud Security Domains

In the Cloud – The Need for Trust

Posted in Security (1500),Virtual - VMWare (30),Visio Samples - Stencils (457) by Guest on the August 25th, 2017

All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place.

  • Trust in this context is establishing understanding between contracting parties to conduct a transaction, and the obligations this assigns on each party involved.
  • Trust models should encompass people and  organizations and devices and infrastructure.
  • Trust level may vary by location, transaction type, user role, and transactional risk.
  • Mutual trust assurance levels must be determinable.
  • Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data.
  • Authentication and authorization frameworks must support the trust model.


Identity, Management, and Federation

Authentication, authorization, and accountability must interoperate / exchange outside of your locus / area of control.

  • People / systems must be able to manage permissions of resources and rights of users they don’t control.
  • There must be capability of trusting an organization, which can authenticate individuals or groups, thus eliminating the need to create separate identities.
  • In principle, only one instance of person / system / identity may exist, but privacy necessitates the support for multiple instances, or one instance with multiple facets.
  • Systems must be able to pass on security credentials / assertions.
  • Multiple locations (areas) of control must be supported.

Access to Data

Access to data should be controlled by security attributes of the data itself.

  • Attributes can be held within the data (DRM / metadata) or could be a separate system.
  • Access / security could be implemented by encryption.
  • Some data may have “public, non-confidential” attributes.
  • Access and access rights have a temporal component. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties / privileges.
  • Permissions, keys, privileges, etc. must ultimately fall under independent control, or there will always be a weakest link at the top of the chain of trust.
  • Administrator access must also be subject to these controls. By default, data must be appropriately secured when stored, in transit, and in use.
  • Removing the default must be a conscious act.
  • High security should not be enforced for everything; “appropriate” implies varying levels with potentially some data not secured at all.
Comments Off on In the Cloud – The Need for Trust

Characteristics of the Cloud Network of the Future

Posted in Security (1500),Virtual - VMWare (30),Visio Samples - Stencils (457) by Guest on the August 18th, 2017

While perimeter defenses may remain in place, they will play a lesser part of the overall protective function and become more distributed. Above depicts scenarios in which the combination of network firewalls and security overlays allows implementation of a typical zone model across the multiple organizations, sites, users and mobile devices that perform the work of the enterprise.


While cautioning that much of the vision of de-perimeterized is not yet practical, there is a clear value in adopting a layered model approach as a targeted security model for the future. The reality of de-perimeterization shifts the emphasis on risk mitigation and investment in policy enforcement mechanisms to resources-hosting systems and applications.



  1. The scope and level of protection should be specific and appropriate to the asset at risk.
  • Business demands that security enables business agility and is cost-effective.
  • Whereas boundary firewalls may continue to provide basic network protection individual systems and data will need to be capable of protecting themselves.
  • In general, it’s easier to protect an asset the closer protection is provided.
  1. Security mechanisms must be pervasive, simple, scalable, and easy to manage.
  • Unnecessary complexity is a threat to good security.
  • Coherent security principles are required which span all tiers of the architecture.
  • Security mechanisms must scale; from small objects to large objects.
  • To be simple and scalable, interoperable security “building blocks” need to be capable of being combined to provide the required security mechanisms.
  1. Assume context at your peril.
  • Security solutions designed for one environment may not be transferable to work in another. Thus, it is important to understand the limitations of any security solution.
  1. Problems, limitations, and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc. Devices and applications must communicate using open, secure protocols.
  • Security through obscurity is a flawed assumption – secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use.
  • The security requirements of confidentiality, integrity, and availability (reliability) should be assessed and built in to protocols.
  • Encrypted encapsulation should only be used when appropriate and does not solve everything.
  1. All devices must be capable of maintaining their security policy on an un-trusted network.
  • A “security policy” defines the rules with regard to the protection of the asset.
  • Rules must be complete with respect to an arbitrary context.

Any implementation must be capable of surviving on the raw Internet; e.g., will not break on any input.

Comments Off on Characteristics of the Cloud Network of the Future

Sample – Word Clinical – Role Based Access Actors and Key Use Cases

Posted in Business (600),O S (375),Security (1500) by Guest on the August 7th, 2016
Comments Off on Sample – Word Clinical – Role Based Access Actors and Key Use Cases

UNIX – Home Directory Policy

Posted in Application,Business (600),O S (375),Security (1500) by Guest on the May 12th, 2016

Home Directory Construction

Policy: Home directories must be constructed in accordance with the following guidelines:

  1. Each log-on account must have a unique home directory. 
  1. Every User must have their own individual account(s) 
  1. Every person’s user-ID must be associated with their home directory. 
  1. Only files unique to the user are to be stored in their home directory. 

Shared files or group projects must be stored on a shared directory 



Home Directory Responsibilities 

Policy: Users are accountable and responsible for all materials found in their home directory.

Only work related material may be held on corporate file servers.

The materials within a user’s home directory are the property of Corporate.

The Systems Administrator will publish backup and recovery procedures for data stored within home directories.


Home Directory Security

Policy: Permissions on a home directory must be set to 700.
If a user decides to make their directory accessible to others, the Systems Administrator must inform the user of the risks involved. The owner of the directory is the first point of contact for any discrepancies found within the directory.

Users are responsible for virus detection on files found within their home directory. This must be done daily. Users who frequently download files from the Internet must scan for viruses after every download.

Users must own all files and subdirectories within their home directories.

File systems containing home directories may not be exported outside the Systems Administrator’s Domain.

Comments Off on UNIX – Home Directory Policy

Sample – Word – AIX Pre – Post Upgrade Checks

Posted in Business (600),Projects (400),Security (1500) by Guest on the March 14th, 2016

Word – AIX Pre – Post Upgrade Checks



Comments Off on Sample – Word – AIX Pre – Post Upgrade Checks
Next Page »