HackDig : Dig high-quality web security articles for hacker

Securing SAP Clouds: Architecture and Operations

2017-01-25 00:00

In this section we discuss several keys differences in application architecture and operations – that have a direct impact on security – you need to consider changing when migrating to cloud services. And it’s these areas that do make operations easier and security better.

As companies move the big, business critical applications to cloud services, they do it backwards. Most we speak with, in an effort to get more familiar with the cloud, opt to leverage cheap storage. Once their toe is in the water – so to speak – they choose to place some development, testing, and failover servers into the cloud in and effort to backstop their on-premise systems. These activities are considered less critical when compared with production servers – production being where firms do not tolerate mis-steps. By default firms design their first cloud systems and applications to mirror those of what they have today in existing data centers. That means they have the same architecture, the same network topology, same operational model, and the security models. It means that your developers and operations teams are working with a model they are already familiar with, can leverage existing skills, thus focusing on learning the nuances of their cloud service. And more often then not, when these teams are up to speed they plan to migrate production systems fully to the cloud. Sounds logical, right? It is, until you move production to the cloud, when it’s exactly wrong.

Long term this approach creates problems. It’s what we refer to as the ‘Lift and Shift’ model of cloud deployment where you try to create an exact copy of what you have today, just running on a service providers platform. The issues are many. This approach fails to take into account the inherent resiliency models of cloud services. It fails to embrace the concepts of automated scale-up and scale-down to be more efficient with resource usage. And from out perspective the real failures are with security capabilities; this approach fails to embrace ephemeral servers, highly segmented networks, automated patching, agile incident response, all of which allow companies to respond to security issues faster, more efficiently and more accurately than what’s possible with existing systems.

Architecture Considerations

Network and Application Segmentation:

Most firms have a security ‘DMZ’, an untrusted zone between the outside world and their internal network, and then a flat internal network structure. There are good reasons why this less than idea setup is commonplace: Segregating networks in a data center is hard to do as users and applications leverage many different resources. To segregate networks often requires special hardware and software and becomes expensive to implement and difficult to maintain. As attackers commonly move from the point where they breach a company network, and either move ‘east/west’ across different servers, or north/south attempting to gain control of applications as well. ‘Pivoting’ in this manner, trying to compromise as much as possible is exactly why we want to segregate networks and applications when possible.

But this is exactly the sort of capability that is provided by default with cloud services. If you’re leveraging SAP’s Hana Cloud Platform, or if your running SAP Hana atop a IaaS provider like Amazon’s AWS, network segregation is the default. Inbound ports/protocoles are disabled by default, eliminating many of the avenues attackers use to penetrate severs. You open only those ports and protocols you need. Secondly, as SAP and AWS are multi-tenent cloud services, individual accounts – and the resources assigned to them – is fully segregated and protected from other users. This means you can limit the ‘blast radius’ of an attackers compromise to the resources in a single account. Application by application segregation is not a new concept, but the ease of use makes it a viable option. In some cases you can even leverage both PaaS and IaaS simultaneously – letting one cloud be the ‘air gap’ to another. Your cloud service provider offers added advantage of running under different user account credentials, roles, and firewalls you define exactly which users can access specific ports, require TLS connections, and limit inbound connections to just approved IP addresses.

Immutable Servers:

There a concept called ‘immutable servers’ that radically changes how you approach security. Immutable servers means the servers do not change once they go into production. It means that you remove the ability to log into the server on port 22. PaaS providers leverage this approach to ensure their admin staff does not and cannot access your underlying resources. For IaaS, it means that there is no admin access to servers; your team only logs in at the application layer of Hana, and the underlying severs do not offer admin logins for the service provider because that capability is disabled. It means both the operating systems and applications you run cannot be changed and the ports and administrative accounts onto those servers are disabled entirely. If you need to update an OS or application, you alter the server configuration or select a new version of the application code in your cloud console, and start new application servers while shutting down the old copies.

At this time HCP does not yet leverage immutable servers, but we have been told it is on the roadmap. Regular, automated replacement is a huge shock that takes most IT operations folks a long time to wrap their heads around, but something you should embrace early to realize the security and productivity gains possible. Not being able to gain admin access to a server is certainly one of those advantages. And auditors love the fact that third parties do not have access.

Blast Radius:

The concept is to limit what resources an attacker can access after an initial compromise. We reduce ‘blast radius’ by not allowing an attacker to ‘pivot’ their attacks elsewhere by reducing the number of services accessible to them. There are a couple of approaches that aid this effort. One is the use of cloud VPC’s and hyper-segregation that is native to cloud services, but which most ports, protocols and permissions needed are unavailable. Another approach is to deploy different SAP features and add-ons in different user accounts, leveraging the natural isolation capabilities built into multi-tenant clouds. If a specific user or admin account is breached, the limit of your exposure is the resources in that account. This sounds radical to some, but it is not particularly difficult to implement. Some firms we have spoken with manage hundreds – or even thousands – of accounts, segregating between development, QA and production systems.

Network Visibility:

Most firms we speak with have a firewall to protect their internal network from outsiders, and identity and access management to gate which users can access SAP features. Beyond that most security is not at the application layer, rather it’s at the network layer. Intrusion detection, data loss prevention, extrusion filtering, user behavior monitoring and similar security capabilities work but inspecting network traffic. When moving to cloud you will be far more reliant on application layer security, and a combination of application logs and agent-based monitors to collect events for security analysis. You need to understand what network oriented security measure become obsolete because there is no corresponding attack vector, and find a suitable replacement for those threats which remain an issue.

Operations

Patching and Change Management:

For the most part firms hate to patch. It requires downtime for servers, synchronizing the efforts of different teams to install patches, and then testing before the applications or servers can go back into production. There are often small manual fixes and configuration changes to make the new code work, staying within the minds of the admins but seldom making back into change management systems. And there is fair chance that a patch may break an application. In that case they have to rollback the patches and recover the servers to previous versions.

One of the biggest mental obstacles for IT and security professionals need to overcome is the idea that we are patching servers regularly, and automating much of the patching and rollout process. With PaaS, infrastructure patching is done for you and on a regular basis. It occurs quietly behind the scenes, without a service interruption, and often without the cloud tenant aware the changes to SAP occurred. The reason they can do this is because the concept of a server is in actuality many virtual servers – behind a load balancer – which are regularly cycled by the service provider to keep them up to date and healthy. But as the platform is fully API enabled, you can leverage these capabilities and roll out patches of your own applications using the Hana cloud.

For IaaS, you run multiple instances of your applications in an auto-scale group behind your load balancer, rolling out new patched instances. You can leave un-patched versions up and running, allowing load balances to re-direct traffic, until your satisfied that you can safely terminate older servers. If something goes wrong with a server or application instance, it’s easiest to replace it with a fresh image. For metadata, network or application settings, you can automate scanning for mis-configurations of your Hana instance, and remediation through the vendor supplied APIs.

In some cases cloud providers may roll out one or more patches a day, so there is a shrinking window of opportunity for attackers to attack known flaws. As a reference to how effective this can be, in the case of the Heartbleed, vulnerability, some cloud providers were able to patch hundreds of thousands of servers in under 48 hours; before attackers to ‘weaponize’ the exploit. From a security standpoint this offers tremendous advantage. It means we do not need to be three, six or twelve months behind on security patches to SAP, servers or out own applications. Essentially, most attackers leverage known vulnerabilities that have not been patched, and fast-flux patches means we patch faster than attackers can react. It also means that if an attacker does manage to compromise one of the servers or application instances, they cannot ‘camp out’ for long as the servers are replaced regularly.

Incident Response:

When a company discovers malware on their network, the long process of discovering which servers are infected begins. And for each of these infected severs, most organizations have to go about physically quarantining the machine, getting backup copies, getting the physical server or server image to the security operations center for analysis, and then requisition a new server. We mention incident response because this operation needs to be entirely re-examined. If your using SAP’s PaaS server for Hana and you believe there has been a compromise, your limited to application layer logs and whatever SAP has contractually guaranteed to provide you, which is typically not much. That said, IaaS and PaaS allows you to automate most of the response effort that had traditionally been manual labor intensive. You can automatically pass logs of infected servers

With IaaS you have even greater control over your resources. With a very small set of API calls to the cloud service, you can isolate the server, pull instance metadata, snapshot all storage and the running instance in memory, change ownership and access rights of the live running instance to the security group, launch analysis tools and simultaneously launch a replacement server. And it all runs within seconds. One of the most time consuming security tasks for IT operations is now nothing more than a utility script that runs in the background. Essentially we are talking about Self-Healing Infrastructure, but the operations and orchestration capabilities which make it a reality.

Fundamentally to realize better security and lower costs you will need to do some re-design on application deployments. To realize the benefits of Agile cloud operations does mean an investment in time to understand how cloud services work, and the time to create the automation scripts that embody the automated patch management, secure deployment and incident response processes. You’ll have to move much of your operations to a continuous integration model, where code and scripts and manifests are automatically assembled, security credentials issued and deployment becomes automatic. Hopefully it is clear that there is a great deal of overlap here with what security teams typically prescribe and how operations teams work. In fact all of these are great productivity advantages create security advantages as well. And the great part is these features are simply part of the cloud service you pay for.

That said there is still a lot of work for you to do as well. To implement segregated application stacks and/or segregated networks, you need to alter the deployment model for applications to leverage the granular isolation model. To leverage ‘best of breed’ cloud services, you’ll re-architect or even break apart applications into smaller services, each running on the cloud best suited for their task. To take advantage of immutable servers means you need to standardize your application configurations and, in the case of Hana on IaaS, script the server startup and configuration process. To leverage the agility possible for patching, you’ll end up changing how you apply and test patches, and the entire process for patch management. And almost all of the work IT used to do for incident response becomes a few lines of automation script, saving operations hours of manual labor, but it does require scripting the process and setting up connections for the security operations team to receive server images. But in the long run it requires less work by your operations teams to manage, and security becomes part of the process.

Previous posts: Securing SAP Clouds: Introduction. Securing SAP Clouds: Contracts

- Adrian Lane (0) Comments


Source: snoitarepo-dna-erutcetihcra-sduolc-pas-gniruces/golb/moc.sisoruces.www

Read:2437 | Comments:0 | Tags: Cloud

“Securing SAP Clouds: Architecture and Operations”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code:

Announce

Share high-quality web security related articles with you:)

Tools

Tag Cloud