DZone Research: Keys to Security

DZone 's Guide to

DZone Research: Keys to Security

Several elements were mentioned as being important to application and data security: 1) access; 2) encryption; 3) depth

· Security Zone ·
Free Resource

To gather insights on the current and future state of security, we talked to 47 executives from 43 companies about security in their own organizations and for the clients with whom they are working. Given all of the breaches that have appeared in the news and the enforcement of GDPR, response to this topic was unlike any we have seen for previous security research guides.

We asked them, "What do you see as the most important elements of application and data security?" Here's what they told us:


  • Flow-based access control — We provide federated access to the same graph – multi-graph. This allows multiple groups to access the same database but only access what they are able to see. Different user groups are able to get the updated information they need with a granular level of control. They need to work within enterprise standards and provide fine-grained access control. 
  • There are four very important elements: people, applications, data, and the cloud. 1) People — 25 percent of all security incidents involve insiders. Getting good visibility into what your employees and contractors are doing with sensitive information by implementing simple Identity Access Management (IAM) solutions can take care of this element. 2) Applications — Applications are the avenue through which 53 percent of successful data breaches occur.  Implementation of modern Application Security Testing (AST) solutions takes care of this element. 3) Data — Encryption should be a standard for every CISO and CIO.  There are many solutions out there and it is a must-have today. 4) Cloud Security — Currently, more than half of all custom applications (60 percent) are being hosted in private data centers.  Over the next year, however, this number is expected to drop by 14 percent. Some 72 percent of businesses deploy critical business applications on AWS. Enterprises can’t afford to have their AWS environment, or the custom applications running in the cloud, compromised. Cloud access security brokers have become an essential element in any cloud security strategy, helping organizations govern cloud use and protect sensitive data in the cloud. 
  • Look at traffic patterns and see where traffic is coming from. Valid credentials cannot be trusted. 2.2 billion credentials are available for purchase from hackers. People reuse passwords all of the time.
  • Identity is becoming the new first line of dense for application and data security. Ensuring that people have the correct level of access to data and applications is quickly moving to the forefront of enterprise security.


  • The security paradigm is upside down. 1) End-to-end encryption. 2) No passwords. All data on the server is encrypted. We keep a private key stored on each device. 3) Administrators — No one administrator can bring the system down.  There is a critical mass of approvers for admins to do massive things. It's really about no longer trusting the server and turning the paradigm upside down. 

  • Applications and data that are run inside the DMZ of an enterprise, or in a cloud service provider's infrastructure, are very well protected with layers of sophisticated tools to prevent abuses. However, once data leaves the security of the DMZ, which inevitably it must from time to time in dealing with customers, partners, and suppliers that data is at risk unless it is encrypted or protected in some other way. E-mail, of course, remains the most widely used intercompany communication tool, with use rapidly expanding for critical communication needs. However, the most widely used methods of encryption for e-mail and its content are deeply flawed in the face of modern working ways and the threat landscape that data in transit faces.  Critical encryption of data, when it leaves the firewall, must be available to all and at the point they need it for all content types and classifications. Additionally, the encryption should be without pre-requisites or sign on to portals. They should also include a rule set that is controlled by the enterprise responsible for the data. This determines how each group should use these tools best, given the sensitivity of the data that they share.  
  • 1) Encryption key and certificate, and assignment and key management. This is a sound security policy as well, with a different module as a platform — manage via Excel. 2) Web application firewall — Offer security teams a way to define the security policy for the organization. 3) Firewall policy management — Provide high-level rules or policies they can define. This can be done by differentiating by an app-centric approach to all of this. The security team used to own security. Now, the application team with DevOps, DevSecOps with guidance from the security team.  
  • Security responsibility — This is about understanding who is responsible for what. The cloud operates under a shared responsibility model, which means that the provider is responsible for some elements of security and the customer is responsible for others. This sounds very straightforward, but it’s actually an area of great confusion. On the one hand, even the shared responsibility model is a bit complicated. Within the cloud, different services—infrastructure, container, abstract—have very different boundaries for enforcing security that are covered under three different shared responsibility models. On the other, it’s easy for customers to make assumptions about who is responsible for security and ignore the separation of responsibilities altogether. The key is understanding those boundaries. A solid understanding of your providers’ shared responsibility model makes it easier to build and maintain a highly secure and reliable environment. 2) Implement security at every level of deployment. Your infrastructure is only as secure as its weakest link. Threats are not limited to external sources. Teams must be prepared to correctly architect against risks, from non-malicious internal breaches or loopholes in user privileges to the most sophisticated attacks, and everything in between. By implementing security measures at every layer of your deployments, you are minimizing the attack surface area of your infrastructure. Amazon Web Services, Microsoft Azure, and Google Cloud Platform offer a range of services and tools that teams can use to design, implement, and architect the proper level of security to protect your data and applications in the cloud. They should have a full understanding of the managed security services offered by all of the cloud service providers that they are using, as well as the knowledge and skills to architect the relevant safeguards within their respective parts of the development and deployment lifecycle. 3) Make encryption business as usual — Last year’s high-profile data breaches left millions of articles of customer data exposed. Under the EU’s GDPR law, which came into effect on May 25, the legal and financial implications of a breach of personally identifiable information (PII) could be fatal for a business. Data that is unencrypted can be read and seen by anyone who has access to it. The nature of the cloud means that data is no longer just on premises, but also in multiple locations. Therefore, there are additional requirements around keeping data secure, whether at rest or in transit. While not mandatory under GDPR, encryption it is one of the best methods that organizations can employ to protect data no matter where it is located. There are a number of different encryption mechanisms that may be used across a multitude of different services. At-rest, encryption can be implemented from the server-side through to the client-side, but you must also use encryption when the data is in transit. Some cloud services focus solely on encryption and may be closely integrated with other services, allowing you to enforce and meet the most stringent of data protection controls across your infrastructure. Teams building in the cloud will want to have a full understanding of the encryption options and mechanisms and how encryption keys are protected and used. Once data is encrypted, it’s important to enforce the correct level of permissions to allow ‘decrypt’ access to that data to only those who need it.
  • Skills and practices — Security has been an issue for many of the data breaches that have received media mention over the past few years. In many of these breaches, it was careless human error and poorly configured security settings in services like Amazon Simple Storage Service (S3) that left customer data exposed, pointing to either a rush job or a lack of experience. AWS has since altered the settings to make those private by default, but that’s only a partial solution and does not compensate for teams who are moving applications to the cloud without security knowledge and experience. The rate of innovation and update makes it a challenge to keep up with the latest services. Cloud providers are increasingly releasing automated services to monitor and detect risks in your environment. This is where security practices, and a culture of security-first, really make the difference in an organization, because it gives teams a mandate to stay connected and informed.  Most importantly, it allows them to keep their skills up to date. 5) Implement permissions based on the principle of least privilege — When setting up new services and solutions, it’s all too easy to grant overly permissive actions to users and identities that require access to your data. This is especially true when troubleshooting access problems. It’s all too common for users to be granted elevated permissions to resolve the issue. In this scenario, the user now has resource privileges above and beyond those necessary to perform their day-to-day job. This poses a security risk from several perspectives. The user could now inadvertently delete or alter the data that they wouldn’t normally have access to. And, if the user's account is compromised by an external threat, those enhanced permissions could have a huge impact on your resources and data. As an improved practice, the administrator should grant specific permissions to users as opposed to global settings for everyone.


  • Defense and depth — There is no magic bullet. It is important to know how to structure applications on the edge. It is also crucial to know how to structure for communication back to the cloud and how to select the framework to make it secure. It's as easy to deploy on the edge as it is in the cloud. There are security solutions in the cloud, but these solutions don’t exist in a smart city application.  There are cost savings by not having to visit remote devices. Many of these things end up being in the cyber existence. The concept of ransomware at a different level than the IT environment. Some customers have Windows 95 with an unsupported OS and no security patches. With that, they need to secure with a VPN. Greenfield microservices for the edge how to structure for better defense and depth. You can quarantine microservices and do forensics on it. The challenge will continue as more devices connect to the internet and new stuff is being created. 
  • There's a need for a safety net. They think access control. Security is about multiple layers and asking, "if this mechanism is breached, what is going to happen?" There are many ways to do encryption that doesn’t provide security. Business owners want security, but service-side encryption does not provide great security, because leaked credentials result in a huge vulnerability. 
  • There are multiple layers across the data lifecycle: 1) Control — know who has access to critical mainframe resources and how; 2) Find — Discover sensitive data that has been lost, hidden, or abandoned; 3) Classify — classify data based on sensitivity level for compliance; 4) Alert — be alerted in real-time of abnormal access attempts; 5) Inspect — deep dive into security issues with advanced reporting and forensics; 6) Audit — prove to auditors that data regulations are satisfied. 
  • It is important to be prepared and not be caught off guard. There has to be a defense in depth layer, as well as multiple solutions and layers. Don’t click on phishing emails. It is important to train users, remain mindful of compromised websites, and practice regular backups and keeping software up to date. 
  • Focused on the website which is different than a server or PC. The website needs to be publicly visible, as well as more open and interactive. There needs to be more sophisticated and automated product given the speed of attacks and change. There needs to be multi-layered to block threats, identify weaknesses, and clean up intrusions
  • There is no single most important thing, instead, it is important to think holistically about both the application lifecycle and integration of security at each layer of the stack. To do this successfully, you must think about development in one of two ways: 1) View development as a chain of Code -> Deployment -> Infrastructure -> Runtime (application) security: With this view, you must increasingly consider software bugs and vulnerabilities as you progress through the chain towards the application layer. As a result, you integrate security holistically into your development cycle. 2) Focus on the layers of trust that exist at each layer of the stack: Roots of trust are established at the very beginning of the development cycle, from the bare metal hardware and boot process, and extend through to the virtual machines, operating systems, and, finally, application security. If you do not think through trust at each layer, and how trust (or lack thereof) at one layer influences the next, then securing your data or applications becomes much harder. Problems at lower levels of the stack can result in “building on top of sand.” It might not matter how secure your application layer is if the lower layers of your stack are fundamentally insecure. You must also consistently ask yourself these two questions to guide the integration of security into your application and data layer: 1) What are the real world threats my application is facing and is it protected from today’s popular attacks at each stage of our dev lifecycle? At each layer of the stack? 2) What are the potential threats that the application can face? Is it protected from these hypothetical future attacks based on the care we’ve put into each stage of our development lifecycle/each layer of the stack?

Stay tuned for our second installment of Keys to Security, covering security when applied to education, data, and security by design.

Here’s who we talked to:

security ,encryption ,appsec ,identity access management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}