Configuration Management for virtual and Cloud Infrastructures

Configuration Management for Virtual and Cloud Infrastructures

The top seven things to consider

May 17, 2013.

By Ronni J. Colville and George Spafford

www.gartner.com

Configuration management is a key process for any IT endeavor — including

legacy IT systems, as well as private and public clouds. Without visibility to the

configuration of the relevant IT service, IT will not be able to manage the

multisourced cloud infrastructure and software.

Organisations adopting virtualisation and cloud delivery services need to review

their configuration management processes to ensure that they are optimised to

support these services.

A review of the configuration management process should focus on, and alter as

required, the process design, including inputs and outputs, workflows, controls,

roles and responsibilities, data models, reporting and opportunities for process

automation.

Through 2015, 80% of outages impacting mission-critical services will be

caused by people and process issues, and more than 50% of those outages will

be caused by change/configuration/release integration and hand-off issues.

As IT adopts technologies such as virtualisation and cloud services, new

dynamics will be introduced (e.g., mobility and offline/online), as well as

opening its doors to external providers (e.g., infrastructure as a service [IaaS]).

This complexity will require IT to add more rigor (not less) to their configuration

management process.

As the number of internal and external service providers increases, the need for

timely, accurate and secure information flows also increases. With any delivery

method, configuration plays a vital role in providing logical views of IT services,

including changes to configurations.

Consider the following questions and responses to rightsise your configuration

management process for virtual and cloud infrastructures:

1. How well are standards defined and followed? Standard implementations

bring predictability and speed in deployment, but the mobility of virtualisation

adds unpredictability in performance, because changes can be done in real time

without an impact assessment. Add a shared infrastructure (e.g., multiple VMs

per host and cluster) and what was standard and predictable for one IT service

will potentially be affected by other IT services. These new dynamics will affect

how standards are assessed and maintained, and will require closer inspection

of how dynamic (versus standard and static) the IT service blueprint should be.

Standards will need to be reassessed on an ongoing basis to ensure scalability

and predictable availability.

2. How well are IT services documented or tracked in systems such as the

configuration management database (CMDB)/configuration management system

(CMS)? The CMDB/CMS will maintain a trusted view using integration and

federation to bring in configuration data from a wide variety of sources. Some

discovery sources can take triggers from virtual infrastructures and become

closer to a "real-time view." This view, coupled with a runtime view for

application performance, will enable better predictive planning. Because having

visibility to public cloud infrastructures can be limited with today's discovery

tools, it is critical for IT organisations to understand the service or application,

and how it is manifested (internally and externally).

3. How well is automation used to discover and execute changes? While IT

resources are often experts, they are still prone to human errors. Using

automation to discover and better target changes will significantly reduce

outages. Automating provisioning without understanding the impact of the

single change to a system or software on the broader IT service or application

may have a negative effect (e.g., outage) systemwide. In addition, with the

frequency of changes to the virtual and cloud infrastructures, coupled with new

agile development and deployment, automation will improve the speed of

changes and reduce the errors to which humans cannot scale, to accommodate

the increase in changes without an increase in errors.

4. How well are audit requirements for contractual and regulatory compliance

addressed? Enterprises can no longer exist without mechanisms that prove

sufficient control is in place. Virtualisation enables the swift and real-time

movement of servers and applications from one place to another. Due to this

type of movement, organisations could fail to comply with restrictions, which

could subject the enterprise to significant consequences. This applies not just to

country- or industry-specific regulations (e.g., payment card industry) or

security-based regulations (e.g., Center for Internet Security[CIS]), but broader

regulations (e.g., the USA Patriot Act) that will impact or support global

enterprises.

5. How well are software licenses tracked and are they accurate? Virtual

infrastructures add mobility and offline dynamics that can present a challenge

for tracking application and software usage. IT organisations will have to be

prepared with documentation and discovery methods that can prove license

instantiation.

6. How well does IT already manage multisourced or multivendor operating

environments? The public cloud is not necessarily new; in many respects, it's

another flavor of outsourcing or software as a service (SaaS). IT organisations

are still responsible for their data, their application availability, etc., but now

there is a middleman. IT organisations that have best practices in place for

multisourced or SaaS infrastructures likely will have less of a challenge adapting

their configuration strategies to the public cloud. IT should seek out lessons

learned from traditional outsourcing vendors and incorporate them for the

broader use cases in the public cloud.

7. What is the degree of business risk that IT organisations will tolerate,

associated with specific types of changes (e.g., to business-critical systems,

preapproved changes, emergency changes, etc.)? Today, changes are controlled

within the IT infrastructure, but cloud infrastructures will take change-impact

assessment beyond the corporate firewall into more "opaque" environments

(public clouds). As the scope of control alters with public cloud scenarios,

business risk factors will need to be re-examined, and existing policies will

need to change to enable a 90% success rate or better.

This report is based on independent technology advisory research from Gartner,

Inc. Gartner delivers the technology-related insight necessary for IT leaders to

make the right decisions every day.

The State of UK Cybersecurity - PKWARE Blog

The State of UK Cybersecurity - PKWARE Blog

Cybercriminals Net Big Payday Targeting Banks - PKWARE Blog

Cybercriminals Net Big Payday Targeting Banks - PKWARE Blog

Important Considerations for Seamless McAfee E-Business Server Replacement - PKWARE Blog

Important Considerations for Seamless McAfee E-Business Server Replacement - PKWARE Blog

List of mandatory documents required by ISO 27001

'By 'Dejan Kosutic on April 09, 2013

   

inShare8

It’s actually funny, but it is rather difficult to find a list of all mandatory documents required by ISO 27001 anywhere on the Internet – this problem came to my attention when one of the readers of my blog told me he had to read several of my articles to assemble this list.
Anyway, a complete list of mandatory documents has two parts: the first part is related to documents which are required in the main part of the standard (clauses 4 to 8), and the second part is related to Annex A.
Mandatory documents required in the main part of ISO 27001
The first part is rather straightforward – most of required documents are listed in clause 4.3.1:

• ISMS scope
• ISMS policy and objectives
• Risk assessment methodology
• Risk assessment report
• Statement of Applicability
• Risk treatment plan
• Description on how to measure effectiveness of controls
• Procedure for document management
• Controls for record management
• Procedure for internal audit
• Procedure for corrective action
• Procedure for preventive action

Records required by the main part of the standard are as follows:

• Records related to effectiveness and/or performance of the ISMS
• Records of management decisions
• Records of significant security incidents
• Records of training, skills, experience and qualifications
• Results of internal audit
• Results of management review
• Results of corrective actions
• Results of preventive actions

Documents for Annex A
This is where it gets confusing – ISO 27001 doesn’t require all the controls from Annex A to be implemented, and it doesn’t clearly indicate how each control should be documented. To learn how to determine which controls to implement, read this article: ISO 27001 risk assessment & treatment – 6 basic steps.
The documents that are mandatory in Annex A (providing that the control is applicable) are the following:

• Information security policy
• Inventory of assets
• Rules for acceptable use of assets
• Definition of roles and responsibilities
• Operating procedures for information technology and communications management
• Access control policy
• List of relevant statutory, regulatory and contractual requirements
• Records provided by third parties
• Logs recording user activities, exceptions, events, etc.

And, here are the documents that are quite commonly used when implementing controls from Annex A, although they are not mandatory:

• Classification policy
• Change management policy
• Backup policy
• Disposal and destruction policy
• Information exchange policy
• Password policy
• Clear desk and clear screen policy
• Policy on use of network services
• Mobile computing and teleworking policy
• BYOD – Bring your own device policy
• Incident management procedure

Which documents do you think should be used in ISO 27001 implementation?
Click here to download a white paper Checklist of ISO 27001 Mandatory Documentation with more detailed information on the most common ways for structuring and implementing mandatory documents and records.

Cloud-service contracts and data protection: Unintended consequences

By Michael Kassner

May 13, 2013, 11:52 AM PDT

Takeaway: There are things your cloud-service (Facebook, Amazon, Google, Dropbox, etc.) contracts aren’t telling you. Michael P. Kassner interviews an attorney concerned about what’s not being said.

“If it’s not private, it’s not protected.”
When I heard Tyler Pitchford mention the above quote in his ShmooCon 2013 talk: “The Cloud, Storms on the Horizon,” I thought he was stating the obvious. I mean duh, if it’s public; of course, it’s not protected. Fortunately for me, I kept watching the video, eventually learning that’s not what Tyler was trying to say.
What’s more, by the end of the video it became apparent that I needed to rethink how and why I use cloud services. Using cloud services could lead to significant legal implications, and ultimately, financial hardships.
If you’re thinking this is yet more chastising to get everyone to read End User’s License Agreements (EULA), it’s not. I’m taking aim at what’s not being said in EULAs and privacy policies.
First things first: who is this guy Tyler Pitchford? And, why does an attorney know so much about IT, especially software? Well, Tyler followed a different drummer prior to seeing the judicial light. He graduated with a B.A. in Software Systems Design. After which, Tyler put his expertise to use. If you ever used the file-sharing protocol BitTorrent, you are probably familiar with his BitTorrent client — Azureus.
I don’t know what more a “non-legalese speaking” guy writing about the legal implications of cloud services could ask for.

The cloud legally is?

Like all good attorneys, Tyler first defined the terms under discussion, in this case — the cloud:

The cloud is loosely defined as services (think Google, Facebook, Amazon, LinkedIn, and a whole host of others) delivered over a network. For our purposes: market-speak for resource and cost sharing.

Tyler added one caveat:

The cloud is an excellent way to maximize your resources, but filled with potential legal pitfalls. The larger your operation, the more hassles you’ll face.

Third-party legal issues

Now to the crux of what I wanted to talk about. It may not be correct legalese, but I call it third-party legal issues — something unfortunate happens that is outside our control. In the legal realm, third party refers to:

An individual or group who does not have a direct connection with a legal action, but is affected by it.

Third-party legal issues are particularly important to those of us who use or provide cloud services. Third-party eDiscovery can affect our personal or company’s ability to function. Tyler provided two real-world examples to explain how serious it can be.
First example: A small web-hosting service rented space to a business for its website. The business came under government investigation. The web-hosting service received a third-party subpoena even though it was not under investigation. The web-hosting service had to hire an attorney, produce documents, and shut down servers for eDiscovery, ultimately spending 50,000 dollars to meet the conditions of the subpoena.
Second example: A mid-sized business located its servers at a colocation facility. The government began investigating the owners of the colocation facility, issuing warrants, seizing everything in the building, including the servers of the mid-sized business even though the owners were not part of the investigation. The exact figure is unknown, but minimally, the mid-sized business was unable to function until the government returned their servers.
As you can see, through no fault of our own, we can suffer some serious digital and financial trauma. Tyler had several suggestions to reduce the fallout from being an innocent participant in a third-party legal action:

• Encrypt, encrypt, encrypt!
• Implement data-retention policies, and follow them religiously.
• Delete redundant copies.
• Quarantine data as much as possible.

Each bullet helps isolate your data or your company’s data from other third-party data stored on the cloud service, lowering the interest level of the civil, criminal, or governmental entity investigating the cloud service or another third party using the same cloud service.
Now that we are up to legalese speed, let’s get to some questions.
Kassner: Everyone mentions we should retain an attorney if we do not understand contracts related to cloud services. What kind of attorney is that? What is your specialty?

Pitchford: Sadly, like all things legal, it depends. Generally, you should be able to talk to any good business litigation or contract attorney to handle a general review of cloud-service contracts. If you’re worried about a specific question (privacy, intellectual-property rights, etc.) then you’d want to speak to a specialist.
As for me, I’m an appellate attorney, which means I deal with cases spanning the entire legal field. That said, the areas where I focus most of my time are mass-torts, complex commercial litigation, constitutional law, cyber law, and intellectual property.

Kassner: If you were tasked with setting up a cloud service for a company, what specifically would you want in the agreement?

Pitchford: I’d want the venue, forum-selection, and choice-of-law provisions (clauses that determine the location of the suit, the forum of the suit, court vs. arbitration; and what laws the court will apply) to match the location of the company headquarters, the main location of their legal offices, or anywhere I know that has laws favorable to the company’s expected battles. Depending on the company’s resources, and various other factors, I’d also consider an arbitration clause.
Specifically related to cloud computing, I’d want a guaranteed uptime with a defined penalty provision even though damages resulting from an outage can be difficult to quantify. I would also want some assurance as to whom I’d be sharing servers with.

Kassner: In your talk, you emphasize the need for companies to create a “data-retention policy.” What is it? And, why is it important?

Pitchford: A data-retention policy defines how long an entity stores data. For example, a company might issue a policy stating employees are only to keep emails for 180 days, or back-up servers should only retain two weeks’ worth of information.
A proper policy needs to balance how much of a data archive the corporation really requires to function versus the risk of a complete failure and an inability to recoup the data. The policy must keep the company functional, but should prevent data hoarding. And here’s why: the more data you have, the more data you’ll have to protect and search through if you’re ever involved in litigation.
A retention policy becomes even more important when you realize that you can be required to provide information as part of a lawsuit against a third party.
Kassner: That’s interesting, Tyler. I was under the assumption that a business or person being served a subpoena would be in trouble if they did not have the asked-for data?

Pitchford: As with all things legal, there’s a catch, and it varies by jurisdiction. The general rule is if you’re aware that litigation is likely, you must preserve relevant information within your control. Put simply, you can’t intentionally delete information relevant to a lawsuit against the company directly, or as the result of a third party, it’s illegal. But if there is no threat of litigation, eliminate the data; then there’s nothing to hand over.
It’s less expensive to explain that all potentially relevant information has been destroyed as part of the company’s retention policy, than it is to sort through umpteen years’ worth of archives.
Kassner: You talked about something rather scary, “plain-view doctrine.” If I understand correctly, the government can charge a person based solely on evidence found while looking for something else. Is that right?

Pitchford: That’s correct. Coolidge v. New Hampshire, 403 U.S. 443 (1971), established the parameters of the plain-view doctrine, but they have since been massaged by the more recent Horton v. California, 496 U.S. 128 (1990).
A common example is the traffic stop; where during the stop the officer notices drugs sitting on the passenger seat. The doctrine, however, is also applicable to electronic information. If an officer were to lawfully seize and search a server as part of a raid on a cloud-service provider, immediately incriminating data located while executing the warrant would, arguably, be subject to the plain-view doctrine.
I should note there’s a split between the jurisdictions on exactly what the limits of the doctrine are as they apply to electronic search, but a full explanation would require an article all itself.

Kassner: Could the government take on a whole service like Dropbox, using a third-party subpoena, and then gather evidence using the plain-view doctrine?

Pitchford: Well, no. If a party turned over information by subpoena than the plain-view doctrine wouldn’t apply because the information was handed over voluntarily, and they could do as they pleased with it.
If, however, we tweak your question a little to seizing an entire cloud service by warrant (think Megaupload), then it’s possible the government could utilize the plain-view doctrine to justify locating any incriminating information seized outside the scope of the warrant. But there are certainly limits.

Waiving privacy

Remember, “If it’s not private, it’s not protected.”
I thought I had better explain what Tyler was trying to get at. Most cloud-service contracts are agreements made between a person or company and a third-party service provider. What’s interesting is they can include clauses which define and or waive any expectation of privacy.

When the agreements contain these types of clauses, data residing on a cloud-service provider’s servers is neither considered private, nor protected under the Fourth Amendment. And even if the agreement contains no explicit waivers, the government can still argue a waiver of privacy simply because you have provided your data to a third party.

The government has used these arguments successfully to get data turned over if a warrant could not be obtained; so, those private comments on Facebook — not so private. Now you also understand why Tyler earlier emphasized “encrypt, encrypt, encrypt.” It is the only way data stored in the cloud is truly private.

Final thoughts

It’s been a long, challenging piece. I’ll end by asking Tyler for his “big picture” view.

I think cloud services are valuable tools, but they’re not the answer to everyone’s problems. When a company is deciding whether to adopt cloud services or not, it’s important they evaluate the full picture, not just how much money it can save by slashing IT budgets. And while there are plenty of discussions about the danger of service outages, there simply aren’t enough discussions going on about the possible legal ramifications.

I definitely wanted to thank Tyler, and his mother for allowing me time today — Mother’s Day — to ask a few last-minute questions. As an extra bonus, here are a few “bits of legal wisdom” from Tyler:
Reasonable Searches

• Ideal: Probable cause required, vetted by the courts, and limited in scope to only what’s required.
• Reality: Government will get the benefit of the doubt, and they’ll take everything. If you balk, they may give some back.

Due Process

• Ideal: You’ll be given equal footing in court to present your case; if the government deprives you of property; you’ll be paid.
• Reality: Courts will typically defer to the government, and there are many exceptions to takings.

Statutes

• Ideal: To strike a balance between your rights, and the ability for the civil and criminal systems to function in a meaningful manner.
• Reality: The laws are outdated, and don’t offer much protection. If you have the means, you may be able to put up a fight, but by that point you’ll already have suffered major loses.

Hacking charge stations for electric cars

Hacking charge stations for electric cars

Hacking charge stations for electric cars

by Mirko Zorz - Wednesday, 15 May 2013.

The vision of electric cars call for charge stations to perform smart charging as part of a global smart grid. As a result, a charge station is a sophisticated computer that communicates with the electric grid on one side and the car on the other. To make matters worse, it’s installed outside on street corners and in parking lots.

Electric vehicle charging stations bring with them new security challenges that show similar issues as found in SCADA systems, even if they use different technologies.

In this video recorded at Hack In The Box 2013 Amsterdam, Ofer Shezaf, founder of OWASP Israel, talks about what charge stations really are, why they have to be ‘smart’ and the potential risks created to the grid, to the car and most importantly to its owner’s privacy and safety.