Browsing category

Application Security

Android, app security, Application Security, Endpoint, Google Play, Malicious Code, Malware, Mobile Applications, Mobile Security, Patch Management, software vulnerability, Supply Chain Security, Third-Party Apps, Threat Monitoring, trojan, Unified Endpoint Management (UEM),

What Happens When Malware Sneaks Into Reputable Hardware, Applications and App Stores?

To avoid malware, you should always get hardware and software from official, authorized and reputable sources and vendors, right? But what happens when those same sources actually contain or deliver malicious payloads?

In recent months, such bad code has appeared out of the box in mobile hardware and in reputable and seemingly legitimate apps from authorized app stores. Perhaps it’s time for a more sophisticated and nuanced policy.

Malicious code is a widespread, harmful and growing problem, and threat actors are increasingly targeting businesses and enterprises, according to Malwarebytes “2019 State of Malware” report. The report found that business detections of malware increased nearly 80 percent over the last year, with the largest increases coming from Trojans, riskware tools, backdoors and spyware.

The report also detailed a growing creativity and sophistication in delivery — including the Holy Grail of attack vectors: delivery through official, authorized and reputable sources. Let’s explore some recent examples.

Digitally Signed, Directly Delivered Malware

Hundreds of thousands of ASUS computers were recently infected by malicious code in an attack campaign known as Operation ShadowHammer. (ASUS has since removed the code with a security update.)

The infection didn’t come by way of insecure websites or email phishing attacks. Instead, it arrived via the ASUS Live Update tool and was authenticated by the company’s legitimate code-signing certificates. The CCleaner-like backdoor scanned for each victim’s media access control (MAC) address, hunting for one of 600 targeted MAC addresses. Once a target machine was identified, a malicious payload of unknown purpose was loaded from a remote server.

This entire series of events began with attackers gaining access to ASUS’ certificates, which were used to sign the code through ASUS’ supply chain, according to researchers from both Kaspersky Lab and Symantec.

Operation ShadowHammer has won instant fame as the poster child for the growing threat of supply chain attacks in which malicious items are installed during a product’s manufacturing, at some point between assembly and reception by the customer, or while being updated with signed and authorized software updates.

Can You Pick Up Some Malware From the (App) Store?

Another efficient way to deliver malware is through applications. This is easiest from unauthorized app stores because they have less sophisticated — or nonexistent — checks for bad code.

But it’s also common for malware to slip past those checks on legitimate app stores. An analysis by Check Point researchers found a particular strain of adware in 206 Android apps on the Google Play store, which were collectively downloaded around 150 million times. These apps were compromised by SimBad malware, which is embedded in a software development kit (SDK) on the apps.

According to Google, the install rate of potentially harmful applications (PHA) from Google Play was around 0.04 percent in 2018. However, that very low rate shouldn’t give comfort; it simply means a PHA install rate of one out of every 2,500 downloads. Therefore, a company with thousands of employees is likely to have at least some PHAs inside its firewall.

In another example, a compromised but otherwise legitimate weather forecast app, developed by Alcatel’s parent company, the TCL Corporation, was available as a standalone app on the Google Play store and downloaded more than 10 million times. The weather app harvested user data, such as location, email address, International Mobile Equipment Identity (IMEI) codes and other information, and sent it to a remote server. The app also subscribed victims to phone number services that incurred charges on phone bills.

What’s more, Alcatel bundled the app on its Pixi 4 and A3 Max smartphones, meaning brand-new phones purchased through legitimate channels actually contained the malware.

To date, it’s unclear how exactly the malicious code got into the weather app. The leading theory appears to be that the PC used by a TCL developer was hacked.

The Worst Thing About Bad Code From Good Sources

Matt Blaze, professor of law and computer science at Georgetown University, wrote in a New York Times opinion piece that despite attacks such as Operation ShadowHammer, it’s still more important than ever to keep software up to date.

In fact, according to Blaze, the most dangerous aspect of the ASUS supply chain attack is the risk that people might turn off automatic updates and avoid installing critical patches.

“It might be tempting to immediately disable these mechanisms … but that would be a terrible idea, one that would expose you to far more harm than it would protect against,” wrote Blaze. “In fact, now would be a fine time to check your devices and make sure the automatic system update features are turned on and running.”

It’s also worth noting that such attacks are far more likely with the prevalence of internet of things (IoT) devices. The future of IT will probably involve far more malicious payloads in legitimate products from authorized sources, but it’s still as important as ever to favor the authorized source over the unauthorized.

Lastly, organizations should always add an extra layer of security by monitoring third-party connections with a unified endpoint management (UEM) solution. The official source, the authorized source and the reputable source are only the first line of defense against increasingly aggressive and creative malware threats, and will continue to function as such. The next lines of defense are up to you.

The post What Happens When Malware Sneaks Into Reputable Hardware, Applications and App Stores? appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Mike Elgan

Application Development, Application Security, Application Security Testing, Application Vulnerability, DevOps, SecDevOps, Software Development, Vulnerabilities, Vulnerability Management,

How to Balance Speed and Security in Your Application Security Program

In today’s ever-evolving digital trust landscape, the term DevOps has become synonymous with speed. If you want to compete, you need to build quality code quickly. Yet as quickly as companies are able to innovate, the bad guys are constantly developing new ways to exploit vulnerable applications.

With that in mind, business leaders and security managers need an application security solution that integrates into the software development life cycle (SDLC) to maintain speed to market. However, there is a delicate balance between security and speed, and striking it is an exercise in understanding your objectives and risks and empowering your developers to lead the charge.

Understand Your Application Security Objectives

If your priority is to simply check the box, so to speak, to satisfy regulatory requirements, it’s important to consider that compliance does not always equal security. That’s not to say achieving compliance is a fast or easy task, but if your goal is to prevent a breach by writing secure software, you need to go beyond just compliance.

Most regulatory requirements are painted with a broad brush and don’t take the nuances of your application into consideration. Compliance is a point-in-time endeavor to check a specific set of requirements that could quickly become irrelevant given the lightning-fast pace of application development. That’s why instituting security throughout the development pipeline is crucial to delivering secure code on time. When security is baked into your application’s DNA from the start, compliance should come easy. Furthermore, you can set yourself apart from the rest of the market by establishing security policies based on the needs of the business.

What Makes a Balanced AppSec Program?

There’s a common misconception that only certain types of application testing can match the speed of Agile or DevOps methodologies. Because of this, many organizations will settle for the type of application testing solution they think satisfies their delivery timelines.

There is no single magic bullet that will provide end-to-end security coverage across your entire app portfolio. Static analysis cannot test for broken authentication, just like dynamic analysis cannot test for insecure data flows. It takes a balanced approach to testing and leveraging different technologies to have a fully mature application security program.

The good news is that application security technology has advanced leaps and bounds over the last decade and is shifting left with the rest of the industry. Static analysis can be integrated at the earliest stages of the development life cycle, and dynamic analysis can be applied to QA testing and even functional testing to only check for certain code changes. Taking the time to understand your risk tolerance and adopting the right blend of technologies can help ensure that you’re delivering quality secure code on time.

Empower Your Developers to Be Security Standard-Bearers

Part of the nuance of balancing security and speed is finding security flaws quickly so you can remediate rapidly. You may have had a high school coach or teacher who taught you how to fail so that you may learn from your mistakes. The same applies to security.

It’s important to recognize real security vulnerabilities early and have an action plan in place to remediate them before they are pushed into production. A major component of this approach is a development team that is backed by a thorough security training curriculum and empowered to take remediation into its own hands. For starters, consider the most common recurring security flaws across your applications, such as SQL injection or cross-site scripting (XSS), and develop a pointed training curriculum to educate developers on recognizing and remediating those flaws accordingly.

Take the time to understand the different types of vulnerabilities and their context within your applications’ design. Naturally, you’ll want to address any high-severity flaws, but also consider whether they can be exploited by an attacker. Is this a critical vulnerability? Is the function within the call path of the application? Chances are, there are dozens of medium-severity vulnerabilities that have a higher risk of exploitation than any of the high-severity ones.

All Apps Are Not Created Equal

Not all applications are created equal, because all applications do not pose the same level of risk across the board. You need to have a way to manage and prioritize your risks — not to mention scarce resources — across your application landscape.

Unfortunately, we don’t live in a perfect world. However, having a grasp of your application landscape, applying the right technology in the right place and empowering your developers to take ownership of secure coding practices will ensure that you don’t have to pick sides in balancing speed and security.

Read our e-guide to learn more

The post How to Balance Speed and Security in Your Application Security Program appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Joe Coletta

Amazon AWS, Application Security, Cloud, Cloud Adoption, cloud computing, Cloud Security, Cloud Services Provider, DevOps, Hybrid Cloud, Security Spending,

Is Cloud Business Moving too Fast for Cloud Security?

As more companies migrate to the cloud and expand their cloud environments, security has become an enormous challenge. Many of the issues stem from the reality that the speed of cloud migration far surpasses security’s ability to keep pace.

What’s the holdup when it comes to security? While there’s no single answer to that complicated question, there are many obstacles that are seemingly blocking the path to cloud security.

In its inaugural “State of Hybrid Cloud Security” report, FireMon asserted that not only are cloud business and security misaligned, but existing security tools can’t handle the scale of cloud adoption or the complexity of cloud environments. A lack of security budget and resources compounds these concerns.

What Are the Risks of Fast-Paced Cloud Adoption?

Of the 400 information security professionals who participated in the survey, 60 percent either agreed or strongly agreed that cloud-based business initiatives move faster than the security organization’s ability to secure them. Another telling finding from a press release associated with the report is that 44 percent of respondents said that people outside of the security organization are responsible for securing the cloud. That means IT and cloud teams, application owners and other teams are tasked with securing cloud environments.

Perhaps it’s coincidental, but 44.5 percent of respondents also said that their top three challenges in securing public cloud environments are lack of visibility, lack of training and lack of control.

“Because the cloud is a shared security model, traditional approaches to security aren’t working reliably,” said Carolyn Crandall, chief deception officer at Attivo Networks. “Limited visibility leads to major gaps in detection where an attacker can hijack cloud resources or steal critical information.”

While the emergence of the cloud has enabled anytime, anywhere access to IT resources at an economical cost for businesses, cloud computing also widens the network attack surface, creating new entry points for adversaries to exploit.

The Misery of Misconfiguration

As cloud-based businesses continue to quickly spin up new environments, misconfiguration issues have resulted in security nightmares, particularly over the last several months. According to Infosecurity Magazine, a misconfiguration at a California-based communications provider left 26 million SMS messages exposed in November 2018, and in December 2018, IT misconfigurations exposed the data of more than 120 million Brazilians.

From Amazon Web Services (AWS) bucket misconfigurations to Elasticsearch or MongoDB blunders, companies across all sectors have had their names in headlines not because of a data breach, but because human error left plaintext sensitive data exposed, often without a password.

Getting Cloud Security up to Speed

As is most often the case, the ability to enhance cloud security comes down to the availability of resources — 57.5 percent of respondents to the FireMon survey said that less than 25 percent of the security budget is dedicated to cloud security.

It’s also time to move beyond the misconception that cloud providers are delivering security in the cloud.

“Organizations new to the cloud will typically think that the cloud provider handles security for them, so they are already covered. This is not true; the AWS Shared Security Model says that while AWS handles security of the cloud, the customer is still responsible for handling security in the cloud. Azure’s policy is similar,” said Nitzan Miron, vice president of product management, application security services at Barracuda.

In short, securing all the applications and databases running in cloud environments is the responsibility of the business. That’s why organizations need to start thinking differently about their security frameworks and how to design controls that will secure a complex, borderless environment. Within that evolving security framework, organizations not only need strategies for scalable threat detection across cloud environments, but the endpoints accessing those cloud environments also need to be able to detect threats.

“Reducing risk will require adding capabilities to monitor user activity in the cloud, unauthorized access, as well as any malware infiltration. They will also need to add continuous assessment controls to address policy violations, misconfigurations, or misconduct by their suppliers and contractors,” Crandall said.

DevSecOps to the Rescue?

Another reason cloud security is lagging is rooted in the highly problematic division of teams. According to Miron, it’s often the case that security teams are separate from Ops/DevOps teams, which causes security to move much slower.

When the DevOps team decides to move to the cloud, it may be months before the security team gets involved to audit what they are doing.

“The long-term solution to this is DevSecOps,” said Miron.

Let it not be lost on anyone that “Sec” is supplanted right between “Dev” and “Ops.” When it comes to development, security is not something that can be tacked on at the end. It has to be central to the DevOps process.

From database exposure to application vulnerabilities, security in the cloud is complicated; and the complexities are compounded when teams don’t have adequate resources. Businesses that want to advance cloud security at scale need to invest in both the people and the technology that will reduce risks.

The post Is Cloud Business Moving too Fast for Cloud Security? appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Kacy Zurkus

Application Development, Application Security, Application Security Testing, Data Protection, MaaS360, Malware, Mobile App Security, Mobile Applications, Mobile Security, Unified Endpoint Management (UEM),

How to Lift the Veil on Mobile Application Security Threats

Mobile applications have revolutionized the way we consume information. Nowadays, most organizations leverage these powerful tools to enhance their employees’ agility with services that are available 24/7. But granting applications access to highly sensitive corporate data also widens the mobile attack surface, which is why it’s crucial to not overlook the associated application security threats.

Mobile Apps Complicate the Data Privacy Picture

A mobile application is like an iceberg; most of its behaviors are executed silently. On one hand, it can be inherently malicious and feature malware that, when hosted on a device, targets the user’s data, credentials, transactions and more. These behaviors are mostly found in applications available on third-party stores, but sometimes also in major commercial app stores. In 2019, Pradeo Lab discovered that 5 percent of Android and 2 percent of iOS apps hosted malicious programs.

On the other hand, a mobile application doesn’t need to be malicious to hurt collaborators’ privacy. Greyware is a category of application that comprises intrusive apps that exfiltrate user data to the network (67 percent of Android apps and 61 percent of iOS apps) as well as vulnerable apps developed without following security best practices (61 percent of Android apps).

Either way, mobile apps have the power to severely compromise corporate data privacy. Today, security heads are stuck with the major challenge of complying with data privacy laws and enhancing user productivity while preserving their agility.

Shed Light on Mobile Application Security Threats in Your Network

Organizations that distribute mobile apps are encouraged — and required by law in some industries — to diagnose their security levels prior to release. To shed light on all aspects of a mobile app, it is necessary to audit it with a mobile application security testing (MAST) tool. MAST solutions perform multidimensional analyses (static and dynamic) that allow security teams to detect all app behaviors and vulnerabilities. This way, organizations can ensure that the apps they are about to release do not threaten the privacy of any corporate or personal data. If they do, this process will help the relevant parties repackage them.

MAST solutions are available as software-as-a-service (SaaS) and sometimes as an application programming interface (API) to integrate within developers’ environments. In addition, some unified endpoint management (UEM) solutions are starting to integrate this kind of service within their platform to facilitate security heads’ experience.

Register for the webinar to learn more

The post How to Lift the Veil on Mobile Application Security Threats appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Vivien Raoul

Application Development, Application Programming Interface (API), Application Security, Application Vulnerability, CISO, Cloud Security, DevOps, SecDevOps, Software, Software Development, software vulnerability,

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.

This post appeared first on Security Intelligence
Author: Atul Chaturvedi

Application Development, Application Security, Authentication, Chief Information Security Officer (CISO), CISO, Cybersecurity Jobs, DevOps, New Collar, passwords, Security by Design, Security Professionals, Security Strategy, Skills Gap, Software Development,

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.

This post appeared first on Security Intelligence
Author: Bill Bonney

Application Development, Application Security, Application Security Testing, Application Vulnerability, Cloud Security, DevOps, Penetration Testing, Risk Management, SecDevOps, Static Application Security Testing (SAST),

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.

This post appeared first on Security Intelligence
Author: Rob Cuddy

Application Development, Application Security, Application Security Testing, CISO, Cloud, Cloud Adoption, Cloud Applications, Cloud Infrastructure, Cloud Security, Cloud Services, Cloud Services Provider, Data Management, Industries, Risk Management,

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.

This post appeared first on Security Intelligence
Author: Brian Evans

Application Security, Blockchain, Data Privacy, Data Protection, Data Security, Encryption, Encryption Keys, IBM Security, Identity & Access, Identity and Access Management (IAM), Identity Governance, Penetration Testing, Security Services, X-Force,

Blockchain: Making the Reward Much Greater Than the Risk

What is the first thought that comes to mind when someone mentions blockchain? Many of you may say bitcoin, which is what’s to be expected considering bitcoin was the first major cryptocurrency that made blockchain a household name. However, bitcoin is only one among a large variety of cryptocurrencies, and while it was the first large-scale implementation of blockchain technology, it is merely one application of many uses by which blockchain can aid society and commerce.

Blockchain technology provides a means to store data in a distributed ledger. The data is stored within a block, where it is digitally recorded and linked together with other blocks, forming a chain. The chain provides the entire history of all recorded data. Data is committed to the chain in the form of transactions. The transactions are only added after they have been validated by the blockchain network’s consensus protocol, so that there is only one version of the truth. Any data stored on the blockchain is “immutable,” meaning it cannot be changed. Also, all network participants have a copy of the data, meaning everything is transparent and everyone has the same version of truth.

The first major implementation of blockchain technology was introduced in 2008 with the release of bitcoin, but it’s only during the past few years that enterprises have come to grasp the technology’s potential. This is happening because the past decade has seen a tremendous reduction in the costs of secure storage, computation power and communications. As a result, more innovation makes its way into mainstream markets, served to average consumers.

The same applies to the business realm. Nowadays, we are starting to see more blockchain adoption across many industries, including financial, food services, healthcare, aviation, automotive and logistics. In 2017, the blockchain market was valued at $708 million. Two separate reports have estimated that by 2024–2025, the market could be valued between $20 to $60 billion. This significant growth represents up to an 8,300 percent increase in the span of less than 10 years.

We are still in the early stages of exploring this technology, and it will take time to fully realize its applications and potential. For example, it took almost 10 years for computers to reach an adoption rate of 80 percent. For enterprises, blockchain technology at scale has only been around since late 2015. So what does this mean, exactly? As we watch a new technology emerge and steadily grow, people who love to be on the cutting edge of technology are excited about the endless possibilities blockchain affords. That said, with new technology also comes new challenges, especially regarding security.

Big Implementations, Limited Experts

The people who deeply understand blockchain infrastructure are typically blockchain developers and architects, whose numbers are increasing, but are still few and far between. If you layer on blockchain security expertise, you will find that number to be even smaller. Hardly any published information or guidance exists about blockchain security.

So what are the implications of developing these full-fledged solutions with little knowledge about the potential attack vectors and risks that could bring the entire system crashing down? Inherently, the decentralized nature of blockchain, coupled with consensus protocols, helps to address some security needs, but the consequences can be dire if security isn’t fully explored.

Blockchain Is Code, and Code Can Be Flawed

As previously mentioned, at its core, the blockchain concept is simple: It is a distributed, immutable, cryptographically assured ledger that can have applications, often called “smart contracts,” interface with it.

A smart contract is made up of numerous lines of code, which are stored within the blockchain. These contracts automatically execute when predetermined terms and conditions are met. They are small programs that replicate processes or business logic and can be used to enforce an agreement between multiple parties in such a way that they can be certain of the outcome without any need for an intermediary.

For example, smart contracts may be used in the healthcare industry. Users’ data, such as blood pressure and other metrics, could be published to a chain, and once a metric rises above a specified threshold, the smart contract could execute actions such as notifying the user and/or processes such as further consultations with specialists to resolve their health problems. A flaw capable of compromising smart contracts could allow an attacker to modify critical details in the code. In the above example, what happens if an attacker is able to affect the business logic or introduce additional code to perform unintended actions?

But as with many powerful technologies, while blockchain is straightforward in concept, if improperly implemented, flaws and vulnerabilities can result in risk and security consequences. Think about what would happen if one could change the smart contract’s data before it is stored on the chain? Data on the chain is supposed to be trusted, right? What about a smart contract flaw that results in business logic not behaving as expected?

In the past few years, X-Force Red has seen a plethora of risks introduced into blockchain ecosystems where it was possible to abuse access controls at the user and administrative levels. For example, some vulnerabilities may enable attackers to inject malicious code into the network, effectively compromising all nodes.

Putting the technology aside, your standard everyday applications (i.e., web/mobile applications) still need to interface with the chain on some level. It has been possible for our penetration testers to compromise these components and pivot to backend systems where there is little to no security, giving an attacker the ability to insert data on the chain or execute any function that is exposed. Functions may include higher-privileged administrative access or accessing data that a user should not have access to. If that happens, how does an environment protect itself against malicious actions?

Raising the Bar on Blockchain Security

Security is about raising the bar high enough that attackers would be extremely hard-pressed to exploit any vulnerability. If they were to attack, they would make enough noise on the network to be detected and incident response procedures would hopefully slam the door shut. So, monitoring from both an application and network level is key to protecting blockchain implementations. Should an internal host be scanning your internal network? I think not!

Another precaution is to take a page out of the renowned television show, “The X-Files,” and trust no one:

  • Build a layered defense where each layer of the solution provides some level of distrust of all the layers above it.
  • Enforce strict access controls both at the application and blockchain layers to prevent overly permissive access and abuse.
  • Ensure there are strong governance controls and processes around the handling of all sensitive information, including key material. Should your certificate authority be disclosed to an unauthorized third party, then it’s game over; they would have full control of your blockchain environment.
  • Implement strong change control and a secure code review process to ensure all configuration settings and source code (i.e., smart contracts) are as secure as possible and do not contain any weaknesses that can be abused.

These are only a handful of basic actions that you can take to help protect the integrity, availability and confidentiality of your blockchain-enabled environment.

At X-Force Red, we have many experienced hackers with blockchain-specific skill sets to perform security assessments and penetration tests on anything within the blockchain technology and connected infrastructure.

IBM is an industry leader in blockchain technology and, as such, our X-Force Red hackers are exposed to numerous areas of the technology while working with leading experts in the field.

This all culminates into possessing a deep technical understanding and the ability to assess any blockchain-enabled solution from an end-to-end perspective. X-Force Red can review the environment from a design/architectural perspective and manually review smart contracts, access controls, configuration of critical components and more. We can also test all applications and technologies that interface with the blockchain, work with key stakeholders and developers to fully realize the potential risks they may face, and assist in reducing the risk of a compromise.

Learn more about X-Force Red’s blockchain testing services

The post Blockchain: Making the Reward Much Greater Than the Risk appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Christopher Thomas

Application Development, Application Scanning, Application Security, Application Security Testing, Application Vulnerability, DevOps, Open Source, SecDevOps, Vulnerabilities, Vulnerability Management,

Take Your Relationship With DevSecOps to the Next Level

Feb. 14 is Valentine’s Day, a day to express affection and celebrate the significant relationships in our lives. For some, it’s a great excuse to enjoy a gourmet meal with a loved one, or maybe even just a glass of wine on the couch. For others, it is a day to make their relationship permanent — according to Bing, 50 percent of marriage proposals happen on Valentine’s Day.

Like any relationship, DevSecOps works best when there is a solid commitment. How can you do something special this year to move the needle and take your relationship with DevSecOps to the next level?

Commit to Application Security Testing

If you really want DevSecOps to work, application security needs to be more than an item on a checklist on the way to production. If we aren’t careful, running a scan can become a lot like the old practice of running a nightly build, which would reveal that code compiled, linked and could be deployed. That is helpful, but here’s the real question: Did you do anything with that build to test, validate and verify it? And what happened when a new build was done the next night? In many shops, QA teams were left testing builds that were days or weeks old, and when defects were found, they didn’t know to which build or configuration they applied, leading to confusion and lost time. In today’s DevOps world, continuous integration is the norm, yielding much more meaningful impact on speed and quality.

In the same way, if we are running scans as part of our DevSecOps pipeline, we are bound to identify vulnerabilities. But what next? Is application security a gatekeeper or simply a to-do? If a vulnerability is found, how is it examined to determine its severity? If it is found to be severe, does that stop the pipeline? Is there a process in place for feedback about security vulnerabilities to get to development teams quickly and in context? To improve your relationship with DevSecOps, you need to fully understand and embrace the notion that application vulnerabilities are critical to the overall quality and success of what ends up in production.

Communicate the Real Issues

We’ve all been in situations where we either misunderstood what someone else was saying or felt we were not being understood — sometimes both at the same time. Or maybe we didn’t have all the information we needed to make the best decision. We can relate to the famous line from 1967’s “Cool Hand Luke”: “What we’ve got here is failure to communicate.”

Great communication in the DevSecOps world elevates security from obscurity to an essential component of consumer trust. It is also the difference between a culture that values security and one that merely tolerates it. With that in mind, let’s explore some critical communication skills that can take your relationship with DevSecOps to the next level.

First, communicate the real issues. We all know that security scans, particularly static application security testing (SAST), can be noisy. Do your teams spend a lot of time chasing false positives? If so, that is just eroding trust and increasing the likelihood of missing something important. It’s time to build trust by leveraging artificial intelligence (AI) and machine learning to help filter those out.

Second, talk about the elephant in the room. According to a Stack Overflow survey, more than half of all developers are contributing to open-source projects, and a GitHub survey found that 98 percent of developers are using open-source tools. Clearly, open source is everywhere, and it provides a lot of power to add software development efforts. But, as Uncle Ben famously said to his nephew Peter Parker in Spider-Man, “With great power comes great responsibility.” Do you have a reliable software inventory? Does it include open-source tools and usage? Does everyone agree on it, and is it well maintained? If you are working with third-party vendors or outsourcing development, are you validating the code you receive, including open-source code? When it comes to open source, we have to ask the hard questions and be willing to have difficult conversations. Rest assured, it’s worth it in the long term.

Third, get to the root issues and deal with them faster. As much as we would love to think all our released code is perfect and secure, we know that isn’t the case. New vulnerabilities are found and exploited every day, and that application we knew to be secure last week could be suddenly vulnerable today. Finding and fixing your false negatives before the bad guys do is critical to maintaining trust. Is your tooling able to help you identify potential blind spots? For instance, can it alert you to the use of a new framework against which there are no tests? If a new exploit is announced, can you quickly and reliably cross-reference it against your software to see your risk?

Build a Winning Security Culture to Overcome DevSecOps Challenges

If you have been in the DevSecOps space for any reasonable amount of time, you know it can be challenging. Constant market pressure to deliver features and capabilities at speed, coupled with a market that is full of similar options, means that competition is everywhere. In this environment, trust is becoming a form of currency, with security and privacy being the key elements — and customers are prioritizing security more than ever before.

But each time you include and document security requirements in an application during design instead of after coding, you build credibility into your DevSecOps. Each time you identify a significant vulnerability and deal with it before production, you further develop that trust. And each time your efforts to shift left result in more developers embracing security testing as an integral part of their code, you establish DevSecOps stability. All of these elements are crucial to building a winning cybersecurity culture.

We all have relationship goals. With a firm commitment, better communication and perseverance in the face of challenges, you will be well on your way to making DevSecOps your Valentine in 2019.

The post Take Your Relationship With DevSecOps to the Next Level appeared first on Security Intelligence.

This post appeared first on Security Intelligence
Author: Rob Cuddy