Introduction to Cloud Security Architecture from a Cloud Consumer's ... [PDF]

Dec 7, 2011 - These platforms provide basic security features including support for authentication, DoS attack mitigatio

14 downloads 43 Views 809KB Size

Recommend Stories


Cloud Security
Nothing in nature is unbeautiful. Alfred, Lord Tennyson

Cloud Security
Be grateful for whoever comes, because each has been sent as a guide from beyond. Rumi

Introduction to Google Cloud Platform
Be who you needed when you were younger. Anonymous

Cloud Computing Security
The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together.

Security of the Cloud
We can't help everyone, but everyone can help someone. Ronald Reagan

hybrid cloud security
Goodbyes are only for those who love with their eyes. Because for those who love with heart and soul

Cloud Computing Security
I cannot do all the good that the world needs, but the world needs all the good that I can do. Jana

cloud computing & security
Those who bring sunshine to the lives of others cannot keep it from themselves. J. M. Barrie

Yanzi From Sensor to Cloud
Open your mouth only if what you are going to say is more beautiful than the silience. BUDDHA

To Cloud or not to Cloud?
So many books, so little time. Frank Zappa

Idea Transcript


BT Your opinion matters! 20% of InfoQ readers are currently using Machine Learning- What about you? Fill in the InfoQ Survey!

About InfoQ InfoQ Writers Contribute About C4Media Exclusive updates on:

Facilitating the spread of knowledge and innovation in professional software development

Search Login

En

Fr Br 1,190,464 Dec unique visitors Development Java Clojure Scala .Net C# Mobile Android iOS IoT HTML5 JavaScript Functional Programming Web API

Featured in Development Towards Memory Safety in Intel SGX Enclave

Yu Ding discusses Rust SGX SDK which combines Intel SGX together with Rust. Developers could write memory-safe SGX enclave easily, eliminating the possibility of being pwned intrinsically. All in Development Architecture & Design Architecture Enterprise Architecture Scalability/Performance Design Case Studies Microservices Patterns Security

Featured in Architecture & Design Charles Humble and Wes Reisz Take a Look Back at 2017 and Speculate on What 2018 Might Have in Store

In this podcast Charles Humble and Wes Reisz talk about Java 9 and beyond, Kotlin, .NET Core 2, the surge in interest in organisational culture, quantum computing, and more. All in Architecture & Design Data Science Big Data Machine Learning NoSQL Database Data Analytics Streaming

Featured in Data Science Get More Bytes for Your Buck

Lovethesales had to classify one million product data from 700 different disparate sources across a large domain. They decided to create a hierarchy of classifiers through utilizing machine learning, specifically Support Vector Machines. They learned that optimising the way in which the svms were connected together yielded vast improvements in the reuse of labeled training data. All in Data Science Culture & Methods Agile Diversity Leadership Lean/Kanban Personal Growth Scrum Sociocracy Software Craftmanship Team Collaboration Testing UX

Featured in Culture & Methods Ramon Harrington of Vistaprint on Choosing What Not To Build

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Ramon Harrington of Vistaprint about his QCon New York talk on Rapid Prototyping All in Culture & Methods DevOps Infrastructure Continuous Delivery Automation Containers Cloud

Featured in DevOps How to be Confident That Your Microservices Can Still Communicate in Production with Pact and Docker

Consumer-driven contracts enable our teams at Rightmove to work independently, and be confident that their changes won’t break other services when deploying their own. It also improves communication between teams, and helps to get developers thinking about API design early on. All in DevOps Podcasts

Software Development Conference LondonMar 5-9, 2018 AI & ML SFApr 9-11, 2018 New YorkJun 25-29, 2018 Streaming Machine Learning Reactive Microservices Containers Java All topics You are here: InfoQ Homepage Articles Introduction to Cloud Security Architecture from a Cloud Consumer's Perspective

Call for articles

Introduction to Cloud Security Architecture from a Cloud Consumer's Perspective

| Posted by Subra Kumaraswamy on Dec 07, 2011. Estimated reading time: 16 minutes | Discuss Share |

"Read later" "Reading List" A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Introduction Cloud application developers and devops have been successfully developing applications for IaaS (Amazon AWS, Rackspace, etc) and PaaS (Azure, Google App Engine, Cloud Foundry) platforms. These platforms provide basic security features including support for authentication, DoS attack mitigation, firewall policy management, logging, basic user and profile management but security concerns continue to be the number one barrier for enterprise cloud adoption. Cloud security concerns range from securely configuring virtual machines deployed on an IaaS platform to managing user privileges in a PaaS cloud. Given that the cloud services can be delivered in many flavors i.e. in any combination of service delivery models, SaaS, PaaS and IaaS (SPI), and operational models, public, private and hybrid, the cloud security concerns and solutions are context (pattern) dependent. Hence, the solution architecture should match these concerns and build security safeguards (controls) into the cloud application architecture. So what are the architectural frameworks and tools that cloud application architects and devops have at their disposal when developing applications for IaaS and PaaS platforms? In this article, I’ll discuss the approach to baking “adequate” security into your application deployed in IaaS and PaaS clouds .

Cloud Security – Shared Responsibility Related Vendor Content

Top 10 AWS Cloud Security Risks Developing an Intelligent Analytics App with PostgreSQL Building Serverless Apps with Azure Cosmos DB and Azure Functions Critical KPIs for a Successful Cloud Migration Building Scalable Web Applications with Azure Database for MySQL Related Sponsor Gain near-instant visibility into the state of your AWS Cloud security. Start your 14 day free trial of the Evident Security Platform. Set-up in 5 minutes. No credit card required. First, let’s talk about the cloud security operational model. By definition, cloud security responsibilities in a public cloud are shared between the cloud customer (your enterprise) and the cloud service provider where as in a private cloud, the customer is managing all aspects of the cloud platform. Cloud service providers are responsible for securing the shared infrastructure including routers, switches, load balancers, firewalls, hypervisors, storage networks, management consoles, DNS, directory services and cloud API. The figure below highlights the layers, within a cloud service, that are secured by the provider versus the customer. (Click on the image to enlarge it)

Prior to signing up with a provider, it is important to perform a gap analysis on the cloud service capabilities. This exercise should benchmark the cloud platform’s maturity, transparency, compliance with enterprise security standards (e.g. ISO 27001) and regulatory standards such as PCI DSS, HIPAA and SOX. Cloud security maturity models can help accelerate the migration strategy of applications to the cloud. The following are a set of principles you can apply when evaluating a cloud service provider’s security maturity: Disclosure of security policies, compliance and practices: The cloud service provider should demonstrate compliance with industry standard frameworks such as ISO 27001, SS 16 and CSA Cloud controls matrix. Controls certified by the provider should match control expectations from your enterprise data protection standard standpoint. When cloud services are certified for ISO 27001 or SSAE 16, the scope of controls should be disclosed. Clouds that host regulated data must meet compliance requirements such as PCI DSS, Sarbanes-Oxley and HIPAA. Disclosure when mandated: The cloud service provider should disclose relevant data when disclosure is imperative due to legal or regulatory needs. Security architecture: The cloud service provider should disclose security architectural details that either help or hinder security management as per the enterprise standard. For example, the architecture of virtualization that guarantees isolation between tenants should be disclosed. Security Automation – The cloud service provider should support security automation by publishing API(s) (HTTP/SOAP) that support: Export and import of security event logs, change management logs, user entitlements (privileges), user profiles, firewall policies, access logs in a XML or enterprise log standard format. Continuous security monitoring including support for emerging standards such as Cloud Audit. Governance and Security responsibility: Governance and security management responsibilities of the customer versus those of the cloud provider should be clearly articulated.

Cloud Security Threats and Mitigation Does cloud computing exacerbate security threats to your application? Which emerging threats are relevant? Which traditional threats are amplified or muted? Answers to these questions are dependent on the combination of cloud service deployment and operational models in play. The following table illustrates the dependencies which should be taken into consideration when architecting security controls into applications for cloud deployments:

Public/Hybrid Cloud -Threats

Private Cloud Threats

Mitigation

IaaS

· OWASP Top 10

· OWASP Top 10

· Data leakage (inadequate ACL)

· Data theft (insiders)

· Testing apps and API for OWASP Top 10 vulnerabilities

· Privilege escalation via management · Privilege escalation via console misconfiguration management console · Hardening of VM misconfiguration image · Exploiting VM weakness · Security controls · DoS attack via API including encryption, multi· Weak protection of privileged keys factor authentication, fine · VM Isolation failure granular authorization, logging · Security automation Automatic provisioning of firewall policies, privileged accounts, DNS, application identity (see patterns below) PaaS

[In addition to the above] · Privilege escalation via API

[In addition to the above]

· Privilege escalation via · Authorization weakness in platform API services such as Message Queue, NoSQL, Blob services · Vulnerabilities in the run time engine resulting in tenant isolation failure In addition to the aforementioned threats to information confidentiality and integrity, threats to service availability need to be factored into the design. Please remember that the basic tenets of security architecture are the design controls that protect confidentiality, integrity and availability (CIA) of information and services. Threat to cloud service availability - Cloud services (SaaS, PaaS, IaaS) can be disrupted by DDoS attacks or misconfiguration errors by cloud service operators or customers. These errors have the potential to cascade across the cloud and disrupt the network, systems and storage hosting cloud applications. To achieve continuously availability, cloud applications should be architected to withstand disruptions to shared infrastructure located within a data center or a geographic region. This vulnerability is best illustrated by the recent Amazon outage when Elastic Block Storage (EBS) brought down customer applications deployed within a single availability zone in US east region. However, applications that were architected to tolerate faults within a region were largely shielded from this outage and continued to be available to the users. As a design principle, assume everything will fail in cloud and design for failure. Applications should withstand underlying physical hardware failure as well as service disruption within a geographic region. Loose coupling of applications and components can help in the latter case.

Cloud Security Architecture – Plan As a first step, architects need to understand what security capabilities are offered by cloud platforms (PaaS, IaaS). The figure below illustrates the architecture for building security into cloud services. (Click on the image to enlarge it)

Security offerings and capabilities continue to evolve and vary between cloud providers. Hence you will often discover that security mechanisms such as key management and data encryption will not be available. For example: the need for a AES 128 bit encryption service for encrypting security artifacts and keys escrowed to a key management service. For such critical services, one will continue to rely on internal security services. A “Hybrid cloud” deployment architecture pattern may be the only viable option for such applications that dependent on internal services. Another common use case is Single Sign-On (SSO). SSO implemented within an enterprise may not be extensible to the cloud application unless it is a federation architecture using SAML 1.1 or 2.0 supported by the cloud service provider. The following are cloud security best practices to mitigate risks to cloud services: Architect for security-as-a-service – Application deployments in the cloud involve orchestration of multiple services including automation of DNS, load balancer, network QoS, etc. Security automation falls in the same category which includes automation of firewall policies between cloud security zones, provisioning of certificates (for SSL), virtual machine system configuration, privileged accounts and log configuration. Application deployment processes that depend on security processes such as firewall policy creation, certificate provisioning, key distribution and application pen testing should be migrated to a self-service model. This approach will eliminate human touch points and will enable a security as a service scenario. Ultimately this will mitigate threats due to human errors, improve operational efficiency and embed security controls into the cloud applications. Implement sound identity, access management architecture and practice – Scalable cloud bursting and elastic architecture will rely less on network based access controls and warrant strong user access management architecture. Cloud access control architecture should address all aspects of user and access management lifecycles for both end users and privileged users – user provisioning & deprovisioning, authentication, federation, authorization and auditing. A sound architecture will enable reusability of identity and access services for all use cases in public, private and hybrid cloud models. It is good practice to employ secure token services along with proper user and entitlement provisioning with audit trails. Federation architecture is the first step to extending enterprise SSO to cloud services. Refer to cloud security alliance, Domain 12 for detailed guidance here. Leverage APIs to automate safeguards – Any new security services should be deployed with an API (REST/SOAP) to enable automation. APIs can help automate firewall policies, configuration hardening, and access control at the time of application deployment. This can be implemented using open source tools such as puppet in conjunction with the API supplied by cloud service provider. Always encrypt or mask sensitive data – Today’s private cloud applications are candidates for tomorrow’s public cloud deployment. Hence architect applications to encrypt all sensitive data irrespective of the future operational model. Do not rely on an IP address for authentication services – IP addresses in clouds are ephemeral in nature so you cannot solely rely on them for enforcing network access control. Employ certificates (self-signed or from a trusted CA) to enable SSL between services deployed on cloud. Log, Log, Log – Applications should centrally log all security events that will help create an end-to-end transaction view with non-repudiation characteristics. In the event of a security incident, logs and audit trails are the only reliable data leveraged by forensic engineers to investigate and understand how an application was exploited. Clouds are elastic and logs are ephemeral hence it is critical to periodically migrate log files to a different cloud or to the enterprise data center. Continuously monitor cloud services – Monitoring is an important function given that prevention controls may not meet all the enterprise standards. Security monitoring should leverage logs produced by cloud services, APIs and hosted cloud applications to perform security event correlation. Cloud audit (cloudaudit.org) from CSA can be leveraged towards this mission.

Cloud Security Principles Every enterprise has different levels of risk tolerance and this is demonstrated by the product development culture, new technology adoption, IT service delivery models, technology strategy, and investments made in the area of security tools and capabilities. When a business unit within an enterprise decides to leverage SaaS for business benefits, the technology architecture should lend itself to support that model. Additionally the security architecture should be aligned with the technology architecture and principles. Following is a sample of cloud security principles that an enterprise security architect needs to consider and customize: Services running in a cloud should follow the principles of least privileges. Isolation between various security zones should be guaranteed using layers of firewalls – Cloud firewall, hypervisor firewall, guest firewall and application container. Firewall policies in the cloud should comply with trust zone isolation standards based on data sensitivity. Applications should use end-to-end transport level encryption (SSL, TLS, IPSEC) to secure data in transit between applications deployed in the cloud as well as to the enterprise. Applications should externalize authentication and authorization to trusted security services. Single Sign-on should be supported using SAML 2.0. Data masking and encryption should be employed based on data sensitivity aligned with enterprise data classification standard. Applications in a trusted zone should be deployed on authorized enterprise standard VM images. Industry standard VPN protocols such as SSH, SSL and IPSEC should be employed when deploying virtual private cloud (VPC). Security monitoring in the cloud should be integrated with existing enterprise security monitoring tools using an API.

Cloud Security Architecture Patterns Architecting appropriate security controls that protect the CIA of information in the cloud can mitigate cloud security threats. Security controls can be delivered as a service (Security-as-aService) by the provider or by the enterprise or by a 3rd party provider. Security architectural patterns are typically expressed from the point of security controls (safeguards) – technology and processes. These security controls and the service location (enterprise, cloud provider, 3rd party) should be highlighted in the security patterns. Security architecture patterns serve as the North Star and can accelerate application migration to clouds while managing the security risks. In addition, cloud security architecture patterns should highlight the trust boundary between various services and components deployed at cloud services. These patterns should also point out standard interfaces, security protocols (SSL, TLS, IPSEC, LDAPS, SFTP, SSH, SCP, SAML, OAuth, Tacacs, OCSP, etc.) and mechanisms available for authentication, token management, authorization, encryption methods (hash, symmetric, asymmetric), encryption algorithms (Triple DES, 128-bit AES, Blowfish, RSA, etc.), security event logging, source-of-truth for policies and user attributes and coupling models (tight or loose).Finally the patterns should be leveraged to create security checklists that need to be automated by configuration management tools like puppet. In general, patterns should highlight the following attributes (but not limited to) for each of the security services consumed by the cloud application: Logical location – Native to cloud service, in-house, third party cloud. The location may have an implication on the performance, availability, firewall policy as well as governance of the service. Protocol – What protocol(s) are used to invoke the service? For example REST with X.509 certificates for service requests. Service function – What is the function of the service? For example encryption of the artifact, logging, authentication and machine finger printing. Input/Output – What are the inputs, including methods to the controls, and outputs from the security service? For example, Input = XML doc and Output =XML doc with encrypted attributes. Control description – What security control does the security service offer? For example, protection of information confidentiality at rest, authentication of user and authentication of application. Actor – Who are the users of this service? For example, End point, End user, Enterprise administrator, IT auditor and Architect. Here is a subset of the cloud security architecture pattern published by open security architecture group (opensecurityarchitecturegroup.org). (Click on the image to enlarge it)

This pattern illustrates the actors (architect, end user, business manager, IT manager), interacting with systems (end point, cloud, applications hosted on the cloud, security services) and the controls employed to protect the actors and systems (access enforcement, DoS protection, boundary protection, cryptographic key & management, etc). Let’s look at details communicated by the pattern.

Infrastructure Security services (controls) at cloud service providers As per the pattern a cloud service provider is expected to provide security controls for DoS protection and protection of confidentiality and integrity for sessions originating from Mobile as well as PC. Typically these sessions initiated by browsers or client applications and are usually delivered using SSL/TLS terminated at the load balancers managed by the cloud service provider. Cloud service providers usually don’t share the DoS protection mechanisms as hackers can easily abuse it.

Application Security Services (in-house or cloud service provider) Security services such as user identification, authentication, access enforcement, device identification, cryptographic services and key management can be located either with the cloud service provider, within the enterprise data center or some combination of the two. The second pattern illustrated below is the identity and access pattern derived from the CSA identity domain. (Click on the image to enlarge it)

This pattern illustrates a collection of common cloud access control use cases such as user registration, authentication, account provisioning, policy enforcement, logging, auditing and metering. It highlights the actors (end user, enterprise business user, third party auditor, cloud service owner) interacting with services that are hosted in the cloud, in-house (enterprise) and in third party locations. This pattern communicates the following:

Identity Security services (controls) at cloud service providers The cloud hosts the following services: Authentication service that supports user authentication originating from an enterprise portal (Local AuthN UI) and typically delivered using SAML protocol. The authenticated session state is maintained in a cloud session store. Account and profile provisioning service supports the provisioning of new accounts and user profiles, typically invoked via SPML (Service Provisioning Markup Language) or a cloud service provider specific API. Profiles are stored in the user profile store. Cloud policy admin service is used for managing policies that dictate which resources in the cloud can be accessed by end users. Using this service, cloud service owners (enterprise) can perform administrative functions and end users can request for access to cloud resources. Cloud policies are stored in the cloud policy store. Logging and auditing service supports dual functions. The first function is event logging, including security events, in the cloud and the second is for audit purposes. Cloud Audit protocols and APIs can be employed to access this service. Metering service keeps track of cloud resource usage. Finance departments can use this service for charge-back as well as for billing reconciliation.

Identity Security services in the Enterprise

In this pattern, a subset of the applications is hosted in the enterprise: Cloud registration UI provides the UI service for end users to register, manage and provision new cloud resources. Authentication and Authorization is enforced by the cloud services. Cloud usage reporting UI is utilized by end users to generate usage reports. Cloud provisioning service is used to provision cloud resources (compute, storage, network, application services). Access control (AuthN, AuthZ) and session management are enforced at the cloud service end.

Identity Security services at the third party location In this pattern, cloud applications rely on identity services offered by a third party and hosted at their location. These services offer support for third party users who will need access to cloud resources to perform business functions on behalf of the enterprise. For example backup and application monitoring services. In this model, user provisioning, authentication and access enforcement functions are delegated to the third party service.

Conclusion By understanding what you can leverage from your cloud platform or service provider, one can build security into your application without reinventing the capability within your application boundary thus avoiding costly “bolt-on” safeguards. A good practice is to create security principles and architectural patterns that can be leveraged in the design phase. Architectural patterns can help articulate where controls are enforced (Cloud versus third party versus enterprise) during the design phase so appropriate security controls are baked into the application design. Keep in mind the relevant threats and the principle of “risk appropriate” when creating cloud security patterns. Ultimately a cloud security architecture should support the developer’s needs to protect the confidentiality, integrity and availability of data processed and stored in the cloud.

About the Author Subra Kumaraswamy is the chief security architect for eBay and leads the team with mission of making eBay the most trusted commerce market place. Prior to joining eBay, Subra was a Security Architect for Oracle's OnDemand Platform Service. Previously, he led various security initiatives including IT identity and securing cloud services at Sun Microsystems. Subra frequently speaks on the topics of identity, cloud and mobile security and is the co-author of the O'Reilly publication "Cloud Security and Privacy - An Enterprise Perspective on Risks and Compliance". Subra is a founding member of the Cloud Security Alliance and co-chair of the Identity and Access Mgmt work group. Subra co-founded Zingdata and Coolsync Inc which were acquired by Knowledge Networks and Blink.com respectively. Subra has held leadership roles at Accenture, Netscape, Lycos and Sun Microsystems. Subra has a Masters degree in Computer Engineering from Clemson University. Subra is CISSP and CISM certified. Twitter: @subrak

References Cloud Security Alliance guidance Trusted Cloud Initiative Building Customer Trust in Cloud Computing with Transparent Security – Sun Microsystems NIST Cloud Computing Reference Architecture Cloud Security and Privacy: An enterprise perspective on risks and compliance by Tim Mather, Subra Kumaraswamy, Shahed Latif – O’Reilly – ISBN: 0596802765 Open Security Architecture (OSA)

Architecture & Design



PCI DSS



Security



Enterprise Architecture



Infrastructure



Patterns



Compliance



Cloud Computing



Cloud Security

Related Topics:

Related Editorial

Practical mTLS: Security without the Headaches Kubernetes 1.8 Improves Security, Stability and Workloads GitHub Launches Security Alerts Beyond OAuth2: End to End Microservice Security Solving Payment Fraud and User Security with ML

Hello stranger! You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience. Tell us what you think Message Please enter a subject



Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Post Message Community comments Watch Thread Close by on View Reply Back to top Close Quote original message Subject

Your Reply

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Post Message Cancel Close Subject

Your Reply

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p Email me replies to any of my messages in this thread Cancel Close OK RELATED CONTENT

Beyond OAuth2: End to End Microservice Security Oct 29, 2017

Solving Payment Fraud and User Security with ML Oct 06, 2017

A 4-Step Guide to Building Continuous Security into Container Deployment Sep 30, 2017

Practical mTLS: Security without the Headaches Jul 19, 2017

Serverless Security and Things That Go Bump in the Night Aug 17, 2017

BLESS: Better Security and Ops for SSH Access Jul 20, 2017

The InfoQ eMag: Cloud Native Nov 16, 2017

Confusion in the Land of the Serverless Nov 13, 2017

Doorman - An Osquery Fleet Manager Jul 26, 2017

Towards Memory Safety in Intel SGX Enclave Jan 03, 2018 Kubernetes 1.9 Supports Workloads API, Container Storage Enhancements and Windows Beta Support Dec 21, 2017 Sponsored Content

AWS Security: An 11 Step Guide The bad guys are continuously looking for your cloud’s weaknesses, so don’t delay in getting your cloud security into shape. The “AWS Security Fitness Guide” will coach you through the necessary exercises to strengthen your cloud infrastructure.

The Six Essentials for DevOps Team Excellence Enterprises are innovating and delivering digital services quicker than ever before. To achieve success, security must be in place. Learn how to maintain agility and security with \"The Six Essentials for DevOps Team Excellence\" Sponsored by RELATED CONTENT Gremlin Releases "Resilience as a Service" SaaS Platform to Enable More Effective Chaos Engineering Dec 20, 2017

Your Top Five Challenges Moving in to the IoT Space Dec 18, 2017

Control Flow Integrity Using Hardware Counters Dec 16, 2017

Architecting a Modern Financial Institution Dec 14, 2017

From Threat Hunting to Crowd Defense Dec 13, 2017 The Hottest Tech Trends in 2018 According to GitHub Dec 11, 2017

Q&A on the Book "A Seat at the Table" Nov 29, 2017

Crushing Tech Debt through Automation at Coinbase Nov 29, 2017

Charity Majors on Observability and Understanding the Operational Ramifications of a System Nov 22, 2017

Injecting Modern Concepts into Legacy Processes Nov 19, 2017

Cybercrime and the Developer: How to Start Defending against the Darker Side Nov 11, 2017

RELATED CONTENT

Practical Monitoring: Book Review and Q&A with Mike Julian Nov 07, 2017

Fighting Online Fraud and Abuse with Large-Scale Machine Learning at Sift Science Nov 06, 2017

What Is "Cloud-Native" Data and Why Does It Matter? Nov 03, 2017

How to Make the Leap: Building Cloud-Ready Applications into the Architecture Oct 27, 2017

Digital Assets: Lessons in Securing What’s Next Oct 24, 2017

Defining Cloud Native: A Panel Discussion Oct 21, 2017

Alluxio: The Journey Thus Far and the Road ahead Oct 19, 2017

Lessons Learned from Fighting Nation States in Cyber Space Oct 19, 2017

User Anonymity on Twitter Oct 12, 2017

Causal Modeling Using Software Called TETRAD V Oct 05, 2017

Hardware & Provisioning Engineering @Twitter Sep 27, 2017

InfoQ Weekly Newsletter Join a community of over 250 K senior developers by signing up for our newsletter

Your email here

Subscribe

Development Towards Memory Safety in Intel SGX Enclave Entity Services is an Antipattern

W3C Releases HTML 5.2 As Official Recommendation Architecture & Design Entity Services is an Antipattern Microsoft Releases Public Preview of IoT Software-as-a-Service Offering Looking Forward to Java in 2018 Culture & Methods Ramon Harrington of Vistaprint on Choosing What Not To Build From a Laptop in a Box to a Successful Product Launch Including Autism – The Person First Data Science Get More Bytes for Your Buck Monitoring Modern Architectures with Data Science Bias in BigData/AI and ML DevOps Xen Hypervisor 4.10 Focuses on Security and Better ARM Support How ING Bank Does SRE How to be Confident That Your Microservices Can Still Communicate in Production with Pact and Docker Home All topics QCon Conferences About InfoQ InfoQ Writers Contribute About C4Media Create account Login QCons Worldwide London Mar 5-9, 2018 AI & ML QCon, SF Apr 9-11, 2018 Beijing Apr 20-22, 2018 São Paulo May 9-11, 2018 New York Jun 25-29, 2018 Shanghai Oct 18-20, 2018 San Francisco Nov 5-9, 2018

InfoQ Weekly Newsletter Join a community of over 250 K senior developers by signing up for our newsletter

Your email here

Subscribe

RSS feed For daily content and announcements For major community updates For weekly community updates InfoQ.com and all content copyright © 2006-2017 C4Media Inc. InfoQ.com hosted at General Feedback Bugs Advertising Editorial Marketing Contegix, the best ISP we've ever worked with. [email protected]@[email protected]@[email protected] Privacy policy BT

We notice you're using an ad blocker We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.

Smile Life

When life gives you a hundred reasons to cry, show life that you have a thousand reasons to smile

Get in touch

© Copyright 2015 - 2024 PDFFOX.COM - All rights reserved.