Governance and Security
Security
Security is the degree of protection to safeguard a nation, union of nations, persons or person against danger, damage, loss, and crime. Security as a form of protection are structures and processes that provide or improve security as a condition.
The five security-related issues with cloud computing that are critical to the success and security of a cloud-based project—and that are not always getting the full consideration they deserve.
1 Internal clouds are not inherently secure.
In the past year, many organizations have foregone using public clouds, choosing instead to build private clouds behind their firewalls. This may be the best solution for risk-averse groups.
These teams, though, need to understand that just because they've built a cloud inside their firewall doesn't mean that their solution is safe. It still takes just one bad apple to spoil the barrel—a single department, user or application that is not behaving as it should.
An organization that is risk-averse enough to avoid the public cloud should be building a secure cloud—possibly the company should be building its dream cloud, which contains all the security controls that it thinks are missing from a public environment. Since the company physically owns the private cloud, incident response can be very swift. Detection capabilities need to be cloud-specific (for example, sensors need to monitor inside the cloud, not just at its perimeter) and operational capabilities such as patch management must be sharp. A vulnerable service that's in a cloud might have greater exposure and risk than the same service in a standard server farm thanks to the shared nature of cloud resources.
2 Companies lack security visibility and risk awareness.
The paucity of security visibility that most providers offer their customers is itself getting plenty of visibility. Obviously, when using a public cloud service, companies must balance the competing factors of control, visibility and cost. This can be a significant issue—reduced visibility results in diminished situational awareness and a questionable understanding of risk. When planning a move to the cloud, an organization needs to recognize this lack of visibility and determine how to best leverage what insight they can get their hands on. Really, this means designing mitigating controls.
At the infrastructure and platform levels, this is straightforward: Log more information in your applications and set systems up to generate alerts when signs of compromise or malicious use are spotted (for example, when files are modified, records are changed more frequently than usual, or resource usage is abnormally high). For software as a service (SaaS), though, these precautions will require more thought.
SaaS providers are beginning to distinguish themselves via security features. Organizations vetting SaaS providers should consider how they will handle risk awareness—does the provider offer usage data that is granular enough to recognize changes in usage? (Monthly billing doesn't really cut it, unless the risk scenario is a malefactor who only attacks on the 29th of the month.)
3 Sensitive information needs safer storage
Safely storing sensitive information is one of the toughest problems in cloud computing. The solution is to encrypt data, but the critical questions are where to encrypt, and how.
The first requirement of successful encryption in the cloud, which some providers do not yet understand (or at least don't practice), is: Do not store the encryption key with the encrypted data. Doing so more or less negates any value gained from encrypting the data.
Several companies make appliances (virtual or physical) that proxy data leaving an office on the way to a cloud service and encrypt or tokenize it before sending it to the cloud. This allows them to use a cloud service without worrying about data loss—as long as they only intend to access the cloud service from behind that appliance.
4 Apps aren't secure
Application security has been getting attention for years. In my mind, its importance increases when an application is deployed to a cloud environment, as the application is more exposed.
One of the biggest mistakes an organization can make is to take an existing application and simply deploy it to a cloud without first considering what new attack vectors this move opens up.
When possible, an application should be re-architected for cloud deployment—this allows parts of the application to scale independently, and to be more distributed and resilient. It's really an opportunity to make an application more secure than ever. Forcing a development team to not use the corporate firewall as a crutch will result in a solid application.
5 Authentication and authorization must be more robust
Of all the problems covered in this article, cloud authentication and authorization has the greatest number of commercial solutions available. This does not mean the issue is easily solved, however. Every organization has its own way to manage authentication and authorization.
First, it must determine if its current authentication system could also work in a secure and reliable way for users in a cloud environment. If the answer is yes, the follow-up question is whether that is also the best way to authenticate cloud services.
Organizations such as the Cloud Security Alliance (CSA) are working to put some shape around the security issues and the ways to address them. The CSA recently released a summary of the strategic and tactical security pain points within a cloud environment, along with recommendations on how to address them. The organization divided the domains into two broad areas: governance and operations.
Domains grouped under governance include:
* governance and ERM
* legal and electronic discovery
* compliance and audit
* information lifecycle management
* portability and interoperability
Domains grouped under operations include:
* traditional security, business continuity and disaster recovery
* data center operations
* incident response, notification and remediation
* application security
* encryption and key management
* identity and access management
Governance
Governance is the act of governing. It relates to decisions that define expectations, grant power, or verify performance. It consists of either a separate process or part of management or leadership processes. These processes and systems are typically administered by a government. When discussing governance in particular institutions, the quality of governance within the institutions is often compared to a standard of good governance.
Cloud governance is essential for enterprises to maintain control over increasingly complex and integrated systems, services and human resources environments.
These are some of the governance issues that needs to be resolved:
Access Controls – Limit access for internal or external teams to specific resources within one or more clouds. Our flexible role-based security allows you to allocate specific levels of access to development, QA and other teams. Integrate into LDAP/AD deployment to extend internal policies into clouds.
Financial Controls – Track and limit spending by project code, customer or department. Each time a new resource is provisioned across clouds, track the cost and limit the spending, per specific budget requirements.
Key Management and Encryption - Security architecture should enforce a separation of roles. Cloud provider has encrypted data, but not the encryption keys.
Logging and Auditing – Log all activity across clouds. Track activity by user through reports or by integrating monitoring and management systems.
API Integration – Leverage internal management systems by integrating with the REST-based API.
With the right governance solution in place, limit risk while reaping the benefits of incorporating cloud computing across organization.
Principles to be followed -
Too Much Liberty Doesn't Actually Work
Today in the cloud, there are a thousand discoveries yet to be made. You can't blindly apply the old rules of IT without risking revolt of users and developers alike. The cloud requires experimentation and works so well with agile precisely because, at the detail level, it's an undiscovered country. That said, the laws of physics still apply. The rules of the road for large-team collaboration need only to be translated, not re-invented from scratch.
Further, different parts of the cloud are at different stages of development. In areas such as expense-claim applications or document management systems, it's OK to experiment with several different cloud solutions across a large organization. Over time, the best one will win, and the migration off the losing system won't be terribly difficult.
When it comes to cloud infrastructure, though, too much liberty yields nothing but chaos and inefficiency. Think back to the multiple gauges of early railroad systems. History shows too many examples where limiting freedom of choice and diversity is much more effective for developing and deploying infrastructure. Look at centralized, communist China vs. decentralized, democratic India today.
Of course, the trick with dictatorship is figuring out exactly where to apply it and when to stop applying it. When it comes to cloud governance, think about the strategic value and "gravity well" quality of an infrastructure element before you mandate it across the organization. Then think about the technical and market conditions that should trigger the end of the mandate.
Federation Works, but it Needs a Central Core of Power
The Constitutional Convention happened because the Continental Congress and the resulting Articles of Confederation were simply too weak to get important work done. In particular, there was a problem of debts, financing and money supply. If every state continued to do only what was optimal for itself, they would never get anything more accomplished as "united states" than they would as 13 independent ones. To seize the future, they knew they had to sacrifice some control and decision-making to the federal government.
One of the reasons good cloud-based applications are easier to use and less expensive to run than traditional apps is because they limit what you can do. For the developer and system administrator, there are only so many buttons to push.
The cloud vendor essentially acts as a governor, throttling excessive change. In a similar way, the Mac is easier to use because it provides a strong hand about the proper UI behaviors and it limits the range of things you can customize. Compare MacOS to Windows or iOS to Android. In the multi-vendor systems, users are given the ability to customize hundreds or even thousands of details. Does your registry have 500,000 keys, or even more?
With all that freedom, users and application writers will make every permutation of those customizations. This leads to untestable chaos. Gartner suggests that an uncontrolled $500 PC can incur $20,000 a year in administrative cost and wasted time. The temptation to hack is unbelievably expensive. Limiting choices can liberate your organization from cost and downtime risk.
The Continuing Rule of Law, Complete with Laws That Evolve
Viewed from an engineering perspective, the federal government is a series of filters—that is, mechanisms for satisfying public opinion without inviting chaos. The Founding Fathers were practical men, and they weren't at all interested in direct democracy or mob rule. The federal system they designed left only the House of Representatives elected by popular vote, and they had the shortest term. That's a high-pass filter. The Senate, the President and above all the Judiciary were selected indirectly, with longer terms. Those are low-pass filters. The Supreme Court was the slowest filter, intended to represent trends that held true for a generation or more.
At the same time, the system—even the Constitution itself—was designed to evolve, and every person in the government had to comply with the rule of law.
In the cloud, you can have lots of unruly experimentation. As soon as one cloud application grows too fast and gains too much mass, though, you'll need to bring it under standard IT governance processes. Even though your processes may be fine, you'll surely need to evolve the rules and criteria to meet the realities of Cloud applications.
For example, the details of cloud security and business continuity reviews are quite different from traditional apps. Meanwhile, the methods of reviewing the TCO of a system are quite different for cloud apps versus on-premises systems. Finally, the politics of system control are night and day—in the cloud, you own essentially nothing except your data (and the metadata that goes with it).
It involves the following topics -