Category Archives: application development

Securing the Microservices Architecture: Decomposing the Monolith Without Compromising Information Security

In the world of software development, microservices is a variant of service-oriented architecture (SOA). It is an architectural style in which software applications that are typically built as monoliths and run in a single process are decomposed into smaller parts. Each of these parts is called a microservice, running independently with its own process.

Creating a mental picture of monolith versus microservices is relatively easy:

Securing the Microservices Infrastructure

Microservices is a great way to redefine large-scale software projects because it is more flexible and allows for on-demand scalability and much shorter release cycles. As a result, forward-thinking organizations have been increasingly moving to the microservices development style. With this architecture’s fine-grained services and lightweight protocols, it can help teams increase product modularity, making applications easier to develop, test, deploy, modify and maintain over time.

Microservices is also good for scalability. If teams want to scale up one component, they can do that without having to scale the entire project. Scaling up can therefore be a lot faster and less costly.

It might sound like microservices is a cure-all for software development woes. But like any other domain, it has its disadvantages; moving to microservices adds complexity and security implications. Regardless of how an application is designed, major gaps could potentially be introduced on the platform level. In microservices, security concerns can get exacerbated due to the various network connections and application programming interfaces (APIs) used to forge communication channels between the components of the microservice architecture. Another issue is that, if not properly designed, the standardized replicable nature of containers could spread out any vulnerability manyfold.

From managing user access to the code all the way to implementing a distributed firewall, one thing is clear: Ditching monolith for microservices may be right for your organization, but the relevant security considerations must be addressed early in the process.

The Microservices Trinity: Cloud, Containers and DevOps

Microservices are containerized and accessed on scale via cloud infrastructures. To make microservices flow effectively, organizations must adopt a DevOps culture where small, multidisciplinary teams work autonomously, applying Agile methodologies and including operations in their scope of responsibility.

This combination of factors can increase overall security risk for the organization in general and, more specifically, through the phases of a microservice-based application project: planning, development and post-deployment operations in cloud-hosted architectures.

Key Concerns: Knowing Where to Look First

In general, organizations nowadays are aware of their overall risk appetite and know that new projects always introduce new risk considerations. With a move to microservices, we are looking at a gradual process that breaks one large, monolithic project into smaller parts, each of which needs to be managed as its own project. Below are a few key concerns to look out for when operating a microservices architecture.

Isolation

Isolation is at the core of the microservices concept. To be an autonomous piece of the overall application puzzle, a microservice needs to be its own island in a sense — architected, created, deployed, maintained, modified, scaled and, eventually, retired without affecting any of the other microservices around it.

One area where isolation is much-needed is on the database level. Monolithic applications where every part of the application can access any part of the databases can, over time, impact performance due to deadlocks, row locks and errors. Microservices, in contrast, can avoid that if isolation is applied — for example, if it is decided that only one microservice will access one data store and integration with the entire database is eliminated. In a security sense, that means more microservices and more data stores to secure. But if done correctly, one microservice will not be able to access the data of another and, if compromised, it will not give way to an attacker moving laterally.

Another area that requires isolation is deployment. The goal is to ensure that each microservice is deployed without impacting others around it and, should it fail, that the effect would not bring down other microservices as well. The biggest challenge typically applies to multitenant applications, which require isolation on both the microservices and data levels, such as in software-as-a-service (SaaS) scenarios.

A Preference for Hybrid Clouds

Developing at scale usually takes place in the cloud, and most organizations have been doing it for years now. That can also mean that any given organization operates different parts of its infrastructure of different clouds with different vendors. Securing microservices will therefore have to be cloud-agnostic and applicable to any environment with relevant controls in place to achieve uniform effectivity across the various cloud infrastructures.

Insecure DevOps Tool Sets

There are some great open-source tool sets out there built for DevOps teams, and they can be used in most Agile developments. What these tools may not always offer is proper security. Integrating open-source tools into the team’s projects requires assessing exposure and adapting controls ahead of integration, as well as reevaluating them over time. Open-source also means access for all, and that often gives way to opportunities for attackers to plant or exploit vulnerabilities and infect tools with malicious code.

Interservice Communications

Interservice communication is typically not a good idea for projects that exist autonomously, but in some cases it is necessary. These channels can be risky and costly if not designed and implemented properly. Securing interservice communications calls for high standards and encryption on the data level where needed.

Managing Data Layers

Each microservice manages its own data. As a result, data integrity and consistency become critical security challenges to reckon with. This is partly because of the intricacy in planning data stores to keep entries once in each store, avoiding redundancy. One store can keep a reference to a piece of data stored elsewhere, but it should not be duplicated across many stores. From a security viewpoint, we are looking at the CIA triad of confidentiality, integrity, availability — all of which must be managed correctly to provide the organization with better levels of performance and continuity than it had in its monolithic days.

Dive Into Microservice Security

Microservice architectures bring agility, scalability and consistency to the development platform. However, security in these environments often lags behind.

A major concern we face in that domain is imposing the right level of isolation based on application type, platform and data in context. We also look at privacy, regulatory concerns and possible security automation to incubate within the DevOps life cycle.

Though DevOps has already made some strides toward integrating security into the development life cycle, there’s still significant work to be done in this space.

Want to learn more? Check out our paper, “Securing Microservice Architectures — A Holistic Approach.”

The post Securing the Microservices Architecture: Decomposing the Monolith Without Compromising Information Security appeared first on Security Intelligence.

Creating Meaningful Diversity of Thought in the Cybersecurity Workforce

The other day, I learned something that great French winemakers have known for centuries: It is often difficult to make a complex wine from just one variety of grape. It is easier to blend the juice from several grapes to achieve the structure and nuance necessary to truly delight the palate.

We are similarly relearning that building diversity into the cybersecurity workforce allows us to more easily tackle a wider range of problems and get to better, faster solutions.

Essential New Facets of Diversity

I don’t want to strain the metaphor too much, but we can certainly learn from our winemaking friends. Just as they search for juice with attributes such as structure, fruitiness and acidity, we search for ways to add the personal attributes that will be accretive to the problem-solving prowess and design genius of our teams. One of my personal quests has been to add the right mix of business skills to the technical teams I have had the honor to lead.

On my personal best practice adoption tour, I have made many familiar stops. I learned and then taught Philip Crosby’s Total Quality Management system and fretted about our company’s whole-product marketing mastery in the ’90s (thank you, Geoffrey Moore, author of “Crossing the Chasm”). Over the last 15 years, I implemented ITIL, lean principles and agile development (see the “Manifesto for Agile Software Development”), applied core and context thinking (“Dealing with Darwin”) to help my teams establish skill set development plans, and used horizon planning (introduced in “The Alchemy of Growth” by Baghai, Coley and White) to assign budget.

Throughout this journey, I kept trying to add the best practices that were intended for development, manufacturing and marketing to the mix. I was just not content to “stay in my lane.” I did this because I believe that speaking the language of development, manufacturing and marketing — aka the language of business — is essential for technology and security.

Innovation and the Language of Business

As a security evangelist, I have long advocated that chief information security officers (CISOs) must learn how to be relevant to the business and fluent in the language of business. A side benefit I did not fully explore at the time was how much the diversity of thought helped me in problem-solving.

We have been discovering the value of diversity of thought through programs such as IBM’s new collar initiative and the San Diego Cyber Center of Excellence (CCOE)’s Internship and Apprenticeship Programs. IBM’s initiative and the CCOE’s program rethink recruiting to pull workers into cybersecurity from adjacent disciplines, not just adjacent fields.

Toward the end of my stay at Intuit, I participated in a pilot program that brought innovation catalyst training to leaders outside of product development. Innovation catalysts teach the use of design thinking to deliver what the customer truly wants in a product. While learning the techniques I would later use to coach my teams and tease out well-designed services — services that would delight our internal customers — I was struck by an observation: People of different job disciplines didn’t just solve problems in different ways, they brought different values and valued different outcomes.

So, another form of diversity we should not leave out is the diversity of values derived from different work histories and job functions. We know that elegant, delightful systems that are socially and culturally relevant, and that respect our time, our training and the job we are trying to do, will have a higher adoption rate. We struggle with how to develop these systems with built-in security because we know that bolted-on security has too many seams to ever be secure.

To achieve built-in security, we’ve tried to embed security people in development and DevOps processes, but we quickly run out of security people. We try to supplement with security-minded employees, advocates and evangelists, but no matter how many people we throw at the problem, we are all like Sisyphus, trying to push an ever-bigger rock up an ever-bigger hill.

The Value of Inherently Secure Products

The problem, I think, is that we have not learned how to effectively incorporate the personal value and social value of inherently secure products. We think “make it secure too” instead of “make it secure first.” When I think about the design teams I’ve worked with as I was taking the catalyst training, the very first focus was on deep customer empathy — ultimate empathy for the job the customer is trying to do with our product or service.

People want the products they use to be secure; they expect it, they demand it. But we make it so difficult for them to act securely, and they become helpless. Helpless people do not feel empowered to act safely, they become resigned to being hacked, impersonated or robbed.

The kind of thinking I am advocating for — deep empathy for the users of the products and services we sell and deploy — has led to what I believe, and studies such as IBM’s “Future of Identity Study” bear out, is the imminent elimination of the password. No matter how hard we try, we are not going to get significantly better password management. Managing 100-plus passwords will never be easy. Not having a password is easy, at least for the customer.

We have to create a new ecosystem for authentication, including approaches such as the intelligent authentication that IAmI provides. Creating this new ecosystem gives us an opportunity to delight the customer. Writing rules about what kinds of passwords one can use and creating policies to enforce the rules only delights auditors and regulators. I won’t say we lack the empathy gene, but our empathy is clearly misplaced.

Variety Is the Spice of the Cybersecurity Workforce

As we strive to create products and services that are inherently secure — aka secure by design — let’s add the diversity of approach, diversity of values and advocacy for deep customer empathy to the cybersecurity workforce diversity we are building. Coming back to my recent learning experience, I much prefer wines that were crafted by selecting grape attributes that delight the palate over ones that were easy to farm.

The post Creating Meaningful Diversity of Thought in the Cybersecurity Workforce appeared first on Security Intelligence.

Application Security Has Nothing to Do With Luck

This St. Patrick’s Day is sure to bring all the usual trappings: shamrocks, the color green, leprechauns and pots of gold. But while we take a step back to celebrate Irish culture and the first signs of spring this year, the development cycle never stops. Think of a safe, secure product and a confident, satisfied customer base as the pot of gold at the end of your release rainbow. To get there, you’ll need to add application security to your delivery pipeline, but it’s got nothing to do with luck. Your success depends on your organizational culture.

It’s Time to Greenlight Application Security

Because security issues in applications have left so many feeling a little green, consumers now expect and demand security as a top priority. However, security efforts are often seen as red, as in a red stop light or stop sign. In others, they are seen as a cautious yellow at best. But what if security actually enabled you to go faster?

By adding application security early in the development cycle, developers can obtain critical feedback to resolve vulnerabilities in context when they first occur. This earlier resolution can actually reduce overall cycle times. In fact, a 2016 Puppet Labs survey found that “high performers spend 50 percent less time remediating security issues than low performers,” which the most recent edition attributed to the developers building “security into the software delivery cycle as opposed to retrofitting security at the end.” The 2018 study also noted that high-performing organizations were 24 times more likely to automate security configurations.

Go green this spring by making application security testing a part of your overall quality and risk management program, and soon you’ll be delivering faster, more stable and more secure applications to happier customers.

Build Your AppSec Shamrock

Many people I talk to today are working hard to find the perfect, balanced four-leaf clover of application modernization, digital transformation, cloud computing and big data to strike gold in the marketplace. New methodologies such as microservice architectures and new container-based delivery models create an ever-changing threat landscape, and it’s no wonder that security teams feel overwhelmed.

A recent Ponemon Institute study found that 88 percent of cybersecurity teams spend at least 25 hours per week investigating and detecting application vulnerabilities, and 83 percent spend at least that much time on remediation efforts. While it’s certainly necessary to have these teams in place to continuously investigate and remediate incidents, they should ideally focus on vulnerabilities that cannot be found by other means.

A strong presence in the software delivery life cycle will allow other teams to handle more of the common and easier-to-fix issues. For a start this St. Patrick’s Day, consider establishing an application security “shamrock” that includes:

  • Static application security testing (SAST) for developer source code changes;
  • Dynamic application security testing (DAST) for key integration stages and milestones; and
  • Open-source software (OSS) to identify vulnerabilities in third-party software.

You can enhance each of these elements by leveraging automation, intelligence and machine learning capabilities. Over time, you can implement additional testing capabilities, such as interactive application security testing (IAST), penetration testing and runtime application self-protection (RASP), for more advanced insight, detection and remediation.

Get Off to a Clean Start This Spring

In the Northern Hemisphere, St. Patrick’s Day comes near the start of spring, and what better time to think about new beginnings for your security program. Start by incorporating application security in your delivery pipeline early and often to more quickly identify and remediate vulnerabilities. Before long, you’ll find that your security team has much more time to deal with more critical flaws and incidents. With developers and security personnel working in tandem, the organization will be in a much better position to release high-quality applications that lead to greater consumer trust, lower risk and fewer breaches.

The post Application Security Has Nothing to Do With Luck appeared first on Security Intelligence.

Security Considerations for Whatever Cloud Service Model You Adopt

Companies recognize the strategic importance of adopting a cloud service model to transform their operations, but there still needs to be a focus on mitigating potential information risks with appropriate cloud security considerations, controls and requirements without compromising functionality, ease of use or the pace of adoption. We all worry about security in our business and personal lives, so it’s naturally a persistent concern when adopting cloud-based services — and understandably so. However, research suggests that cloud services are now a mainstream way of delivering IT requirements for many companies today and will continue to grow in spite of any unease about security.

According to Gartner, 28 percent of spending within key enterprise IT markets will shift to the cloud by 2022, which is up from 19 percent in 2018. Meanwhile, Forrester reported that cloud platforms and applications now drive the full spectrum of end-to-end business technology transformations in leading enterprises, from the key systems powering the back office to mobile apps delivering new customer experiences. More enterprises are using multiple cloud services each year, including software-as-a-service (SaaS) business apps and cloud platforms such as infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS), both on-premises and from public service providers.

What Is Your Cloud Security Readiness Posture?

The state of security readiness for cloud service adoption varies between companies, but many still lack the oversight and decision-making processes necessary for such a migration. There is a greater need for alignment and governance processes to manage and oversee a cloud vendor relationship. This represents a shift in responsibilities, so companies need to adequately staff, manage and maintain the appropriate level of oversight and control over the cloud service. As a result, a security governance and management model is essential for cloud services that can be found in a cloud vendor risk management program.

A cloud vendor risk management program requires careful consideration and implementation, but not a complete overhaul of your company’s entire cybersecurity program. The activities in the cloud vendor risk management program are intended to assist companies in approaching security in a consistent manner, regardless of how varied or unique the cloud service may be. The use of standard methods helps ensure there is reliable information on which to base decisions and actions. It also reinforces the ability to proactively evaluate and mitigate the risks cloud vendors introduce to the business. Finally, standard cloud vendor risk management methods can help distinguish between different types of risks and manage them appropriately.

Overlooked Security Considerations for Your Cloud Service Model

A cloud vendor risk management program provides a tailored set of security considerations, controls and requirements within a cloud computing environment through a phased life cycle approach. Determining cloud security considerations, controls and requirements is an ongoing analytical activity to evaluate the cloud service models and potential cloud vendors that can satisfy existing or emerging business needs.

All cloud security controls and requirements possess a certain level of importance based on risk, and most are applicable regardless of the cloud service. However, some elements are overlooked more often than others, and companies should pay particular attention to the following considerations to protect their cloud service model and the data therein.

Application Security

  • Application exposure: Consider the cloud vendor application’s overall attack surface. In a SaaS cloud environment, the applications offered by the cloud vendor often have broader exposure, which increases the attack surface. Additionally, those applications often still need to integrate back to other noncloud applications within the boundaries of your company or the cloud vendor enterprise.
  • Application mapping: Ensure that applications are aligned with the capabilities provided by cloud vendors to avoid the introduction of any undesirable features or vulnerabilities.
  • Application design: Pay close attention to the design and requirements of an application candidate and request a test period from the cloud vendor to rule out any possible issues. Require continuous communication and notification of major changes to ensure that compatibility testing is included in the change plans. SaaS cloud vendors will typically introduce additional features to improve the resilience of their software, such as security testing or strict versioning. Cloud vendors can also inform your company about the exact state of its business applications, such as specific software logging and monitoring, given their dedicated attention to managing reputation risk and reliance on providing secure software services and capabilities.
  • Browser vulnerabilities: Harden web browsers and browser clients. Applications offered by SaaS cloud vendors are accessible via secure communication through a web browser, which is a common target for malware and attacks.
  • Service-oriented architecture (SOA): Conduct ongoing assessments to continuously identify any application vulnerabilities, because the SOA libraries are maintained by the cloud vendor and not completely visible to your company. By using the vendor-provided SOA library, you can develop and test applications more quickly because SOA provides a common framework for application development.

Data Governance

  • Data ownership: Clearly define data ownership so the cloud vendor cannot refuse access to data or demand fees to return the data once the service contracts are terminated. SaaS cloud vendors will provide the applications and your company will provide the data.
  • Data disposal: Consider the options for safe disposal or destruction of any previous backups. Proper disposal of data is imperative to prevent unauthorized disclosure. Replace, recycle or upgrade disks with proper sanitization so that the information no longer remains within storage and cannot be retrieved. Ensure that the cloud vendor takes appropriate measures to prevent information assets from being sent without approval to countries where the data can be disclosed legally.
  • Data disposal upon contract termination: Implement processes to erase, sanitize and/or dispose of data migrated into the cloud vendor’s application prior to a contract termination. Ensure the details of applications are not disclosed without your company’s authorization.
  • Data encryption transmission requirements: Provide encryption of confidential data communicated between a user’s browser and a web-based application using secure protocols. Implement encryption of confidential data transmitted between an application server and a database to prevent unauthorized interception. Such encryption capabilities are generally provided as part of, or an option to, the database server software. You can achieve encryption of confidential file transfers through protocols such as Secure FTP (SFTP) or by encrypting the data prior to transmission.

Contract Management

  • Transborder legal requirements: Validate whether government entities in the hosting country require access to your company’s information, with or without proper notification. Implement necessary compliance controls and do not violate regulations in other countries when storing or transmitting data within the cloud vendor’s infrastructure. Different countries have different legal requirements, especially concerning personally identifiable information (PII).
  • Multitenancy: Segment and protect all resources allocated to a particular tenant to avoid disclosure of information to other tenants. For example, when a customer no longer needs allocated storage, it may be freely reallocated to another customer. In this case, wipe data thoroughly.
  • Network management: Determine network management roles and responsibilities with the cloud vendor. Within a SaaS implementation, the cloud vendor is entirely responsible for the network. In other models, the responsibility of the network is generally shared, but there will be exceptions.
  • Reliability: Ensure the cloud vendor has service-level agreements that specify the amount of allowable downtime and the time it will take to restore service in the event of an unexpected disruption.
  • Exit strategy: Develop an exit strategy for the eventual transition away from the cloud vendor considering tools, procedures and other offerings to securely facilitate data or service portability from the cloud vendor to another or bring services back in-house.

IT Asset Governance

  • Patch management: Determine the patch management processes with the cloud vendor and ensure there is ongoing awareness and reporting. Cloud vendors can introduce patches in their applications quickly without the approval or knowledge of your company because it can take a long time for a cloud vendor to get formal approval from every customer. This can result in your company having little control or insight regarding the patch management process and lead to unexpected side effects. Ensure that the cloud vendor hypervisor manager allows the necessary patches to be applied across the infrastructure in a short time, reducing the time available for a new vulnerability to be exploited.
  • Virtual machine security maintenance: Partner with cloud vendors that allow your company to create virtual machines (VM) in various states such as active, running, suspended and off. Although cloud vendors could be involved, the maintenance of security updates may be the responsibility of your company. Assess all inactive VMs and apply security patches to reduce the potential for out-of-date VMs to become compromised when activated.

Accelerate Your Cloud Transformation

Adopting cloud services can be a key steppingstone toward achieving your business objectives. Many companies have gained substantial value from cloud services, but there is still work to be done. Even successful companies often have cloud security gaps, including issues related to cloud security governance and management. Although it may not be easy, it’s critical to perform due diligence to address any gaps through a cloud vendor risk management program.

Cloud service security levels will vary, and security concerns will always be a part of any company’s transition to the cloud. But implementing a cloud vendor risk management program can certainly put your company in a better position to address these concerns. The bottom line is that security is no longer an acceptable reason for refusing to adopt cloud services, and the days when your business can keep up without them are officially over.

The post Security Considerations for Whatever Cloud Service Model You Adopt appeared first on Security Intelligence.