devopsy.kinsta.cloud

Tag: security

What is Security Policy Orchestration and Why Should DevOps Teams Care?
After attending the DevOps day I wrote about in my last post, I wanted to take a minute to explain exactly what Security Policy Orchestration actually is so we can begin to understand how the two concepts overlap.

Simply put, Security Policy Orchestration is intelligent network change automation. It goes beyond simple task automation by truly understanding the network through simulation and analytics. It also gives security people an extra level of governance and control, which is so critical to assure security and business continuity.

Security Policy Orchestration reflects the growing relevance that managed security policies are having on IT systems. In network security lingo, security policies are firewall policies, but can also apply to Access Control Lists (ACLs), router and load balancer configurations. Managing security policies is an arduous task that requires automation, and Security Policy Orchestration has emerged in response to numerous factors happening in tandem – mainly, that:
- Business agility is gaining importance as a key competitive factor. This is creating an increased demand for automation across IT and, specifically at the network layer.
- IT organizations are pressured to match the speed, convenience and self-service provisioning the cloud environment offers for internal application deployment.
- Enterprise networks are growing larger and more complex with numerous traffic routing and shaping technologies to service multiple data centers.
- The widespread use of stateful and next-gen firewalls for external and internal network segmentation has significantly increased the size of the enterprise firewall estate, forcing security policies to morph into complex rule sets that map how business is conducted over the network.
The collective impact of these developments on network and security operations tasks is having a profound impact on people, processes and technology, including DevOps groups, who like their Security Operations (SecOps) brethren, are under pressure to roll out services faster.

Security Policy Orchestration helps to alleviate that pressure, enabling SecOps teams to keep up with the demands of the business while ensuring security and preventing an outage or a breach. Being able to automatically generate, provision and synchronize Security Policy changes across a growing set of systems – with security, compliance and governance concerns accounted for – means that security will not become a bottleneck that slows down DevOps teams.

While Security Policy Orchestration evolved out of network security operations, its benefits transcend security. Even though it will remain a SecOps function, its impact on DevOps is only going to increase, especially as Network and Security Operations continue to converge. However, the fundamental enabler of Security Policy Orchestration is automation.

As a result, there is significant common ground between DevOps and SecOps when it comes to automating application connectivity. This may not have been an issue for you yet, but my introduction to DevOps came from my experiences helping Tufin customers automate application connectivity. It’s a subject that is extremely germane to DevOps teams, and a topic that I plan to explore in depth in this blog because those of us leading the Orchestration charge within SecOps are kindred spirits with DevOps evangelists.

Contrary to popular belief, Security Policy Orchestration wasn’t created to restrict a company but to free it and help DevOps teams to accomplish its vision at the lowest IT risk level possible. After all, there is no such thing as bulletproof security where the Internet is concerned.

Instead, security folks focus on reducing risk, which puts us in a much better position to add value to the business. Plus, since so many of today’s biggest threats (i.e. APTs, for example) are network-based, introducing the tenets of Security Policy Orchestration – which literally automates best security practices into change processes – is in the mutual best interest of both SecOps and DevOps teams.

In my next post, I plan to dig into more detail on the stakes Security, Dev and Ops all share to make IT work faster, better and safer, and propose a few ways in which SecOps and DevOps teams can collaborate to gain some quick wins.
March 18, 2014
DevOps: An Opportunity to Build a Better Resiliency

Security professionals like to check code for security-related defects before the code is delivered. When they start hearing about multiple builds a day, or even a few builds a week, and a radical decrease in development time along with operational changes, they are bound to give pause. After all, most are having a hard time keeping up even now.

The industry is moving in this direction. An Evans Research survey of more than 600 software development professionals in the UK and US found that 51% of respondents have already started the practice of continuous delivery across a number of teams. The same survey found that both culture and technology are the primary stumbling blocks, with 53% believing that they have the technology in place for continuous delivery and 59% believing that their staff is ready.

However, those that do successfully make the move to continuous delivery and embrace DevOps find that the real impact on security will be much brighter than the naysayers predict, according to those interviewed. In fact, it is automation that underpins continuous delivery and much of the DevOps movement, when done properly, goes a long way to enhance security and system resiliency.

Security often gets blamed for slowing down the development process, explains Andrew Storms, senior director of DevOps at CloudPassage. But the reality is that it slows it down no more than QA and other development checks. “Those who are at the end of the chain are typically the ones who get the fingers pointed at them. They are the ones who are blamed for slowing down time to market, or delays in getting product in front of the customers,” says Storms “DevOps is an opportunity to integrate all of that together.”

“One of the interesting things about moving to DevOps is that it requires a very high level of automation,” says David Mortman, chief security architect at Dell Enstratius and a contributing analyst at security research firm Securosis. “Part of the whole continuous deployment model is the move to continuous building and continuous integration. So you need to start writing security-oriented tests that can be automated against that code; when you are running your regression, integration, and other tests, you are testing for security states as well,” Mortman says.

Jeff Sussna, founder of the IT service innovation consultancy Ingineering.IT, agrees “In continuous delivery and DevOps you start thinking, from a nonfunctional requirements perspective, about continuous integration—and that’s about finding software problems sooner, when they’re easier to fix. That’s what security professionals have been fighting for, for years,” Sussna says.

That certainly makes DevOps an easier sell to information security teams. “When you suggest to security teams that security scans be completed with every build so that problems are found sooner, my experience is that security folks, who don’t seem to smile a lot, suddenly start to smile,” Sussna says..

It’s not just talk, “it works,” says Sussna. “When we run those kinds of scans, we find problems earlier, and it’s easier to fix them. When it comes to running through the traditional gates that security puts up, it’s a lot less painful because they tend to run clean within the processes.”

Another, and perhaps much more subtle, yet deep, benefit, is how continuous security testing keeps security at the forefront of developers’ minds. “Even when a build comes back clean, and the notification says, ‘Security violations, zero,’ it puts in their minds—daily—that security is something they need to think about it. And it’s not confrontational; DevOps puts it within the development process because the developers are seeing the feedback from their reporting tools, and so they are getting instant feedback that they need to fix security issues. Therefore, the feedback isn’t a nag from QA or information security; it’s coming from their systems,” .

The benefits of DevOps can run still deeper. “Forget the deployment. Forget the automation. Just having this culture of sharing and working together that DevOps fosters, as opposed to being combative, helps to drive excellence,” says Mortman.

March 18, 2014
DevOps and Security Are Compatible

When I speak with information security organizations faced with the prospect of moving to DevOps, one of the most common fears I hear is that this transition will degrade security of infrastructure and applications. If you’re one of these folks, I understand this fear but you can rest assured: when you do things correctly security will actually improve.

One big reason security benefits in this model is due to improved alignment and tighter feedback loops. You see, DevOps is about creating a unified, engaged team and doesn’t make it easy to fall into the “silo thinking” that traditionally leads to security as an afterthought.

DevOps embraces automation and consistency, which benefits security by allowing you to add automated checks during coding to look for obvious security issues and flag things for human review (such as the linking of new libraries or the introduction of new third-party components that could add risk). This means you will be able to identify “areas of concern” earlier in the development process where they will be much cheaper and more timely to address. Twitter is a well-known advocate of this kind of automation, in which security checks are executed each time code is checked in and obvious security issues are presented to the developer immediately, giving them a chance to correct the problem right away and reducing the likelihood they will repeat the errors. That is a much more effective process than the delayed feedback typically associated with manual code reviews.

Security isn’t just better in the “Dev” portion of DevOps – you can also add automated configuration validation and scope checking into the environment build process to minimize the chance that a fat-fingered error or an out-of-policy change will introduce problems into production.

This sort of automated approach also improves as you learn from retrospectives and post-incident reviews. As you encounter preventable issues, you can often improve your automated checks to increase the odds of catching these issues before they impact production.

Remember that security is an important stakeholder in the DevOps process, and the onus is on you to become a part of the conversation and find ways to add value to the goal of the organization. Also, don’t forget to tap into the community of DevOps practitioners – others have walked this path before you and can help you in your journey.

Finally, if there are specific security challenges related to DevOps that are vexing you (myths you would like to see busted) I’d love to hear from you. Leave a comment below and become part of the conversation.

March 17, 2014
Security Policies For DevOps 101

A while back I was talking with some friends about how to ensure security inside a devops environment. The simple first thought was that no where does DevOps say to do away with security. Instead, consider how your existing information security practices and policies need to adjust given the changes that DevOps brings to the working environment. Veteran security professionals understand that many security practices begin with policies. Furthermore, no policy is ever set in stone. Failing to update policies and procedures at least every year is already a recipe for disaster.

I tell a lot of people to think back when the iPhone was first introduced. The natural tendency of security professionals inside IT organizations was to either 1) simply ignore the device or 2) establish a flat out denial kind of policy. Neither choice was even near the right answer. I can say first hand that I was victim to this kind of tunnel decision making. We updated our mobile device policies with a flat out “no iPhone for you…come back in 2 years” doctrine. My feeble attempts to fend off iOS devices lasted maybe a year. Meanwhile, lots of people at the office were seen with iPhones in hand who continuously said things like “but I’m not using it for work”. Flat out denial on both mine and their parts.

Bottom line, policies are meant to be changed for the changing environments. DevOps is no different.

The Minimum Requirements

Just like in development how we talk about the minimum viable product, we can apply the same concepts to implementing security practices. For starters, make sure your organization has a few policies drawn up, agreed upon and stamped with the approval of your executive staff. The minimum set of policies any organization needs should include: network or Internet security, computer security, information and intellectual property security policies; secure software development policies and procedures.

Be the Champion

But the job doesn’t stop at policy creation. Even having your executives agree to the policies doesn’t mean they will be followed or even understood by your DevOps teams.

I speak to security heads often and tell them they need to get out of their seats and speak to all the employees in a company. One of the first conversations to have is to begin championing the security policies. Make sure people understand the policies and more importantly understand the reasons for the policies which have been selected.

Do you remember going to high school and being told you have to follow a rule that you thought was totally asinine? Non security folks will probably think the same about silly policies and might even act out purposely against them. A champion needs to teach and live those policies. And when someone challenges the policies, then take the time to have a two-way conversation with them. Make sure you understand their point of view first before you try and push your silly security ideals on them.

Taylor Your Policies

While the policy template available online, like those available from SANS, are a great starting place, don’t just slap those on the intranet as-is. Read them and make adjustments for your company, for your culture and your development practices. Even better, include policies that are specific to cloud and DevOps.

One area of customization to start with is to create policies for specific cloud vendors. For example, consider setting policies around how to the company should be using the Amazon’s IAM feature. Make specific policies around how IAM users and groups should be configured and used. Use the doctrine of least privilege and design a sane access control policy. Consider a policy where only a few trusted users have full admin access and other users are in a power users group where they can launch instances, but cannot alter AWS console configuration or access. You might want to give your accounting team limited access to the console as well to review billing and usage. While you are at it, develop specific policies around the use, distribution and storage of cloud API keys. Furthermore, consider enforcing two factor authentication. These kinds of specific use case policies will go a long way for security teams in gaining confidence with the DevOps teams.

DevOps might be the cool new hotness that is making waves in every kind of organization, but that doesn’t mean we can forget our information security requirements in a DevOps environment. One of the starting points in ensuring DevOps organizations follow good security practices is to start with a minimum set of security policies. Make sure you champion these policies and tailor them to your specific organization and use case. With a little luck and determination even your DevOps teams can follow security best practices.

March 13, 2014
Why Baking Security Into the DevOps Framework is Vital to Its Success

I attended my first official DevOps conference in Israel in September 2013. But I was initially introduced to DevOps by my customers – firewall and network managers who, through their efforts to automate security policy management, found themselves dealing with a new and like-minded set of IT stakeholders – DevOps teams.

They said DevOps was also all about automation – automation that allowed IT to increase their business contributions by enabling new applications and other IT services to be rolled out faster with greater control and efficiency.

Conceptually, it was clear to me that the DevOps value proposition is just as relevant to Security as it is to Operations and Development groups, especially since Security teams apply automation with the same fervor as DevOps.

In fact, using automation to accelerate IT has caught hold in the network security world to fuel a new movement and class of solutions, called Security Policy Orchestration. As the CTO of Tufin, a Security Policy Orchestration company, I could not help but recognize the synergies. I was (and still am) intrigued by DevOps, so when I heard about the conference, I decided to go.

And I am so glad I did.

The alignment between DevOps and Security Policy Orchestration is obvious. They both champion the use of automation to accelerate the pace of business. We Security Policy Orchestration folks are just coming at it from a different area within the organization. Kindred spirits, right?

In theory, absolutely, but in reality…not so much.

The conference as a whole was great. It completely validated my theories regarding the synergies between Security Policy Orchestration and DevOp. But what surprised me was that security was a topic that was not being discussed at all at the conference.   Maybe a hat-tip to application security, but network security was not even on the DevOps radar, at least not at this particular conference.

It needs to be. For DevOps, to really be able to move the needle, we have to work together. If history has taught us anything, it’s that when new applications and services are not created or rolled out with security in mind, at some point we will have to go back and retrofit it back in.

Envision the typical experience:   the development team builds a new application, brings IT Operations in to implement it. Once that is done, IT Ops prides itself on all the corkscrewing it took to make the application work on the actual infrastructure. Except for once the app is in production, it doesn’t work. The troubleshooting begins. Invariably, issues of network connectivity come up. Solving them requires app, dev and security managers to break down the cultural and organizational barriers that exist within their organizations to work together to ensure the application is architected correctly into the network. This starts and the process of change requests between AppDev and IT to get the app up and running.

If that process is not automated, it can take months longer than it needs to resolve everything.   Not to mention any company subject to PCI has to consider terms like secure zoning, a concept that is not second nature to DevOps folks.   If PCI is not an issue, there are plenty of other internal and regulatory mandates and security –related considerations that, if for no other reason than common sense, can exponentially reduce the chances of a company ending up in the headlines due to an APT.

These are just a couple of many scenarios that can be avoided if development, IT and security work together from the get go.

The net/net is that Dev and ops have the same goal but they are siloed, which is slowing down the pace of business – inhibiting it. Collaboration is not some warm and fuzzy team-building thing – it is a fundamental business requirement.

And that’s why I am so excited to have the opportunity to do this blog. I think I can add a unique perspective on how DevOps and Security can work together to reach our common goals.

My next post will explain will dig into what Security Policy Orchestration actually is, so we can begin to tease out the similarities and determine how to build on that to true alignment and partnership.

Stay tuned as the drama unfolds! This should be fun….

March 11, 2014
The Unexpected Benefits of DevOps

There are many well and widely known benefits of DevOps, including rapid software delivery, a higher degree of enterprise agility, increased system resilience, and being able to swiftly identify and resolve problems.

But what unexpected benefits have been experienced by organizations that are already down the DevOps path? Kevin Behr, chief science officer at Assemblage Pointe, says that one is the move to continuous improvement. “We’re seeing organizations move to continuous improvement because, as it turns out, the DevOps teams lend themselves very well to continuous improvement and cross-functionality,” he says.

While working with a current enterprise, Behr explains how the company established a continuous improvement IT team in the same spirit as the continuous improvement culture at the automaker Toyota. “The development and operations teams are doing this and they’re solving some really, really crazy problems really quickly. You couple the collaborative mindset of DevOps with continuous improvement and you see stunning results,” he says.

One of those outcomes includes hybrid thinking among collaborating teams. “I witnessed a developer using a checklist the other day. That’s something you never see. Developers are typically all about how many scissors they can run with pointed at their eyes. They are about creativity and danger,” Behr says.

However, after working more closely with the operations teams, the developers tend to start adopting some of the tactics employed by ops teams. “The developer explained how the operations team provided a pre-handoff checklist, because items often were forgotten before release,” Behr says.

The tighter coupling with developers is also changing the perspectives of operation team members. “Operations people typically have this fortification versus resilience mentality. They build big turrets, and they’ll put a big gun down. Now, having worked with more nimble dev teams, they’re wondering how—when the big gun fails—they can react more quickly,” says Behr. “You never often hear ops people talk like that,” he says.

Another surprise is increased security. While some organizations fear that the rapid release cycles and the autonomy within DevOps would derail security efforts, many are experiencing quite the opposite. “I think that existential fear is present in security professionals, as well as a lot of test and QA professionals,” says Gene Kim, founder and former CTO at IT security firm Tripwire, and author of The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. “In observation, however it is the exact opposite. No longer does infosec do the testing work. QA and infosec now will be the consultative authorities to help developers do the testing. They will either write the tools that help increase the quality or help developers write their own tests. We no longer become the bottleneck that people try to figure out how to go around. Instead, we are actively helping them do their daily work. It’s the opposite of preordained failure; it’s active involvement,” says Kim.

Another unexpected outcome that resulted from security becoming more integrated with DevOps is an emphasis on relevant metrics, explains Bill Burns, former director of information security for a U.S.-based major on-demand Internet streaming media provider. “If the security team identifies an important capability or service to build into a new service or product, then, just like other business units, security teams should proactively prepare to present metrics for the risk items they discussed,” he says.

As Burns explains, operations teams see this more clearly as development and operations capabilities merge: the business has an expectation to have key operational metrics available all the time to support decision making. Security is no exception. And having security metrics as part of the same dashboard or review process builds trust and credibility toward the security team. “It also forces the security team to really focus on what the key threats or risks are, how they to measure them, and why the business should care,” says Burns. “This level of relevancy is great, another way for security teams to communicate and work with business units—something every security (should) strives for,” he adds.

The next unexpected benefit—more work for the security team—is both good and bad news, explains Burns. “We’d engage with one team on one particular project, and out of the blue we would get that same person or one of his peers come to us proactively and request our input on other initiatives. Those were exceptional moments for me. You would have a small success with one engagement and you would build trust, and then you find other developers come to you and seek advice. That’s a huge indicator of success right there,”

March 11, 2014
DevOps – A wake up call to security vendors

DevOps is changing the way IT works. Through a collaboration of development and IT teams, organizations can achieve tremendous scale at increased speed to deploy and maintain critical applications and infrastructure. The key technologies of virtualization and configuration automation have made this possible. Without these technologies, development may not slow down, but deployment would slow to a crawl and the benefits of DevOps would be minimal.

It is interesting to note that in almost no definition of DevOps is the security process discussed as a key element. In some cases you will hear mention of improved security through consistent configuration management enabled through automation, but security teams are not at the DevOps table. Why is that? I would suggest that for most people security is considered a barrier to IT. Not surprisingly, DevOps, a practice focused on streamlining IT, security has been left out of the conversation so as to not prevent achieving the goal.

But if you accept that security needs to remain a part of the story, then it must be just as manageable as the infrastructure or it will never have a seat at the DevOps table. Take a look at Puppet or Chef; they automate the configuration of the systems necessary to run the applications. Through automation scripts, systems are deployed, configured, updated, and managed. Development boxes are configured consistently with production boxes limiting impacts related to deploying an application into production. So why can’t security fit into this picture?

One reason, is a lack of standardization. Every security vendor wants to be unique. They promote their solution as so incredibly unique from their competitors that there is no way to standardize. So, creating scripts to manage security would require not only a unique script for each vendor, but a unique solution. In comparison, the command to edit a route in Linux may be slightly different than in Windows, but the parameters are the same. When you are managing security rules on a firewall as an example, you can’t even get agreement on that. Zones are required for some firewalls, not used in others. Applications define access in Palo Alto, but don’t exist in Cisco. Even firewalls that share the idea of Applications use non-standard dictionaries of Applications. So, creating a script becomes a non-standard solution. Worse yet, the script that worked today won’t necessarily work tomorrow when the vendor changes their solution.

To make it all unmanageable, is the fact that they are so proud of their uniqueness that they have obscured even how they do it. If you take all the firewall vendors on the market, not one of them publishes an API on how to fully manage their firewall policies. Palo Alto exposes some capabilities for object management in a cool SDN sort of way. Check Point has a very powerful, but proprietary API that allows full management, but they do not recommend it be used in that way. Cisco is straight up command line with some newly available API’s and should be commended for making it at least obvious how to do it, if not easy.

The result: security is not a big part of the DevOps picture today. And if the vendors don’t do something, they will be replaced by solutions willing to operate in this new DevOps world. Open source firewalls or integrated firewalls in the virtual stack for example are ready to take their place.

The solution for security vendors: publish API’s to fully manage their systems. They must accept that their UI is no longer what differentiates them from their competitors, it is the security engine and enterprise manageability. Make it possible for others to manage their solution through open API’s with their full support. All the security vendors will not come together and agree on a single API, but each should at least publish a usable API for their own product. Vendors like FireMon or open source contributors to solutions like Puppet and Chef will solve the rest.

Security vendors better wake up or they will get left behind.

March 11, 2014
The Fourth Seat at the IT Service Velocity Table

Agile. Devops. SDN.

Development. Operations. Network.

Notice anything missing? How about security? On the one hand, that could be because we’ve finally managed to realize that security is an integral part of every aspect of IT and it’s by default embraced by the other three groups already.

I’ll pause while you stop laughing and catch your breath.

On the other hand, it could be because it’s like every other technological movement and advancement and we’ve simply plowed ahead without considering security until, as is always the case, someone remembers that security is important too. If development, operations and the network teams are going to have an answer to improving the speed with which applications get from the IDE to the end-user’s iPhone, then shouldn’t security have a seat at that table, too?

Absolutely.

It can be argued, in fact, that some areas of security already have a seat at the service velocity table. Consider automated pen testing, virtual patching and continuous vulnerability assessment services. These are often continuous processes that integrate (sometimes) with existing systems or, at a minimum, with some process through which aberrations can be noted and addressed.

It’s important to note that this – and devops – isn’t a plea for automation. Automation and orchestration are tools in a toolbox that may or may not be a fit for a particular tasks or process. Most enterprise organizations, for example, refuse to automate changes to data center firewall rules. Not because it can’t be done – it can – but because the ramifications of a change going wrong is too great to take even the small risk that might be incurred.

But in the interests of speeding up the deployment process (in which security is – or should be – a significant player) there are likely adjustments that can be made to align security with other groups already adopting more agile methodologies.

For example, consider that along with agile development often comes a “nightly build” of the software, designed to ensure that changes don’t break the complete package. It might be beneficial for application security-focused assessments to be inserted into that process, to test early and often the security profile of the software being developed. This helps in two ways: first, it ensures that developers can be made aware of potential vulnerabilities while they’re actively developing the software. That’s important because one of the precepts of agile is move quickly and by the time you’ve found a vulnerability in the released software the developers are already half way through the next spring and not thinking about what they just tossed over the wall.

Second, if there are vulnerabilities that turn up that developers can’t, for some reason, address you have a head start in figuring out how to mitigate them. If that requires a security service of some kind, you’ve got time to get the right policies into place before the application hits the Internet and becomes a target.

There are plenty of ways in which agile methodologies can be adopted by security professionals. One of the precepts of devops is getting outside the silos that exist within the organization and communicating with the other folks seated at the “get the application to the user” table. Being more involved with development and operations and even the network will enable security to integrate more fluidly with the increasingly agile processes that drive the application lifecycle.

March 11, 2014
CA Technologies Launches Industry’s First Management Cloud for Mobility
Solutions to Secure the Mobile Enterprise and Accelerate Innovation to Capture Growth in the Global Mobile Economy
February 24, 2014 09:00 AM Eastern Standard Time

Mobile World Congress 2014
BARCELONA, Spain–(BUSINESS WIRE)–MOBILE WORLD CONGRESS– Today at Mobile World Congress, CA Technologies (NASDAQ:CA) launched the industry’s first, comprehensive Management Cloud for Mobility. Delivered as a cloud service, this portfolio enables enterprises to manage, secure and grow their business, increase productivity and deliver an enhanced mobile experience.

“The growth of mobile devices and apps in the enterprise is blurring the lines between personal and corporate data and leading to new challenges for enterprises”

“The explosion of new devices, applications, content and transactions in the mobile environment has opened new challenges for enterprises of all sizes, worldwide. The CA Management Cloud for Mobility will help enterprises transform the challenges of the new mobile economy into significant opportunity,” said Ram Varadarajan, general manager, New Business Innovation, CA Technologies. “With solutions that power innovation, drive productivity and accelerate the development of new mobile applications and offerings, CA is extending its leadership in IT management to help businesses capitalize on the next technological and business shift – mobility.”

The portfolio includes three complementary solution suites: Enterprise Mobility Management (EMM) to manage and secure mobile devices, applications and content; Mobile DevOps to accelerate application development and deployment; andEnterprise Internet of Things (IoT) to enable the adoption of internet-connected devices. The complete EMM suite and key products of the Mobile DevOps suite are available for purchase. Customers have the choice and flexibility to deploy the complete portfolio of solutions or individual components, with the ability to customize and scale cost effectively.

This CA Management Cloud for Mobility is powered by Smart Containerization™ technology. Unlike traditional device-focused mobility management techniques, Smart Containerization™ allows enterprises to manage the security, performance, compliance and support characteristics of the device, application, content or email while preserving the quality of the mobile user experience.

“The growth of mobile devices and apps in the enterprise is blurring the lines between personal and corporate data and leading to new challenges for enterprises,” said Chris Hazelton, Research Director, Mobile & Wireless, 451 Research. “The EMM space is evolving as companies are looking for more complete offerings that support customers and productive mobile employees. Secure container technologies must provide enterprise scalability and comprehensive security across app development, delivery and support, all while preserving the familiar native look and feel of nearly any mobile device an employee chooses to carry.”

Enable Enterprise Mobility Management

The EMM suite enables enterprises to drive employee productivity and satisfaction by simplifying the management and security of devices, applications, content and email.

The four products within the EMM suite available for purchase are:

New CA Mobile Application Management (CA MAM): Provides security, management and control of mobile applications with fine-grained access control polices for mobile applications.

New CA Mobile Content Management (CA MCM): Enables secure content access and collaboration through file synchronization, access to enterprise content repositories and cloud store integration made available to the end user through policy-based mobile access.

New CA Mobile Email Management (CA MEM): Provides users with secure access to their corporate email and ensures group and policy-based controls to protect sensitive email content.

CA Mobile Device Management (CA MDM): Delivers comprehensive capabilities to provision, secure and manage mobile devices, and deploy mobile applications automatically or through an enterprise app store.

Accelerate Mobile Application Delivery

The Mobile DevOps suite helps enterprises accelerate the delivery of user-experience-focused mobile applications. It enables enterprises to achieve faster time to market by accelerating continuous application delivery while enhancing security. Working across multiple development tools, languages and methodologies, Mobile DevOps makes it easy to build and test rich API-based mobile applications, gain deep insights into performance, user experience, crash and log analytics, and automate and support these mobile applications when deployed onto millions of devices.

The four products within the Mobile DevOps suite available for purchase are:

New CA Layer 7 API Portal: Simplifies publishing APIs, onboarding developers, and streamlines enterprises’ ability to rapidly develop applications based on these APIs.

New CA Layer 7 Mobile Access Gateway: Delivers unified access across web and mobile, authenticates users based on risk levels and protects the datacenter against rogue applications.

CA LISA Test for Mobile: Offers mobile and web developers global access to a comprehensive platform that simulates an exhaustive list of user scenarios for testing.

CA LISA Service Virtualization: Allows customers to test new mobile applications in simulated environments.

Additional Mobile DevOps capabilities will be available in the next few months, including mobile APM, crash and log analytics, user experience analytics and remote application support.

According to a Forrester Research report, “Development shops are just starting to grapple with the biggest change to system architecture since the rise of client/server in the early 1990s: omnichannel clients deployed on smartphones, tablets, and other connected devices. The mobilefirst focus these organizations adopt, forces application architects to think differently about the APIs clients use to access data and functionality.”*

Manage and Grow in the Ubiquitously-Connected Tomorrow

Enterprise IoT will enable businesses to deploy internet-connected devices, and manage and secure billions of Machine-to-Machine (M2M) interactions. Ubiquitous connectivity, advancements in big data analytics and the ability to embed computing into everything have led to the rise of the IoT phenomenon. The Enterprise IoT suite will provide enterprises a secure foundation to extend mobility with IoT infrastructure to achieve business efficiencies.

These Mobility offerings from CA are further supported by significant advances in the CA Security portfolio. These include new and updated identity-based solutions that help customers secure their growing portfolio of cloud services and mobile applications.

For more information on the various solutions supporting mobility from CA Technologies, please visit: http://www.ca.com/us/mobility.aspx.

*The Forrester Wave™: API Management Platforms, Q1 2013, Forrester Research, Inc., February 5, 2013.

About CA Technologies

CA Technologies (NASDAQ: CA) provides IT management solutions that help customers manage and secure complex IT environments to support agile business services. Organizations leverage CA Technologies software and SaaS solutions to accelerate innovation, transform infrastructure and secure data and identities, from the data center to the cloud. Learn more about CA Technologies at www.ca.com.

Follow CA Technologies

Twitter

Social Media Page

Press Releases

Legal Notices

Copyright © 2014 CA. All Rights Reserved. One CA Plaza, Islandia, N.Y. 11749. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
February 24, 2014
CloudPassage to Speak on Cloud Security at RSA Conference 2014 and AGC Partner’s Annual Information Security & Technology Growth

SAN FRANCISCO, CA – CloudPassage, the leader in Software Defined Security (SDSec) and creator of Halo, today announced that CEO and co-founder Carson Sweet will discuss cloud security in the wake of Edward Snowden at AGC Partners’ 10th Annual Information Security & Technology Growth Conference on Monday, February 24. Later that week at RSA Conference 2014, CloudPassage’s Senior Director of DevOps Andrew Storms and Eric Hoffmann, Director of QA, will both lead a discussion on building a model for shared responsibility between security and DevOps teams.

In his panel discussion, Sweet will discuss the security challenges and considerations for hosting data in public, private and hybrid cloud environments. As businesses migrate to cloud environments at a rapid pace, many struggle to understand the different regulatory and legal requirements that come with hosting data outside of their organization as well as what is needed to retain more control of their data in the cloud.

At AGC Partners’ 10th Annual Information Security & Technology Growth Conference:

What: Data Protection in a Cloudy World
When: Monday, February 24, 2014 from 2:15-3:00 p.m.
Where: Westin San Francisco Market Street
Metropolitan III – 2nd Floor
50 Third Street, San Francisco, CA 94103

At RSA Conference 2014, Storms and Hoffman will discuss how the self-service and on-demand nature of the cloud allows developers to work fast faster than security operations teams can keep up. Security professionals are tasked with ensuring compliance without slowing down their increasingly agile DevOps teams.

At RSA Conference 2014:

What: Secure Cloud Development Resources with DevOps
When: Friday, February 28, 2014 at 9:00am
Where: San Francisco Moscone Center West Room 2002

About CloudPassage
CloudPassage is the leading Software Defined Security (SDSec) company and creator of Halo, the industry’s first and only security and compliance platform purpose-built for elastic cloud environments. Halo’s patented architecture operates seamlessly across any mix of software-defined data center, public cloud, and even hardware infrastructure. Industry-leading enterprises trust Halo to protect their cloud and software-defined datacenter environments. Headquartered in San Francisco, CA, CloudPassage is backed by Benchmark Capital, Meritech Capital Partners, Tenaya Capital, Shasta Ventures, Musea Ventures and other leading investors. For more information, please visit http://www.cloudpassage.com

CloudPassage® and Halo® are registered trademarks of CloudPassage, Inc.

February 20, 2014