With today’s increasing Mobile Enterprise Security Threats, do you have a strategy to mitigate the risk on your Corporate Network?

/in , , , , , , , , , , , , , , , , , , , , , , , /by

Corporations are increasingly utilizing mobile enterprise systems to meet their business objectives, allowing mobile devices such as smart phones and tablets to access critical applications on their corporate network.  These devices provide advanced technologies over traditional desktop clients, such as: information sharing, access from anywhere at any time, data sensors, location, etc. But what makes these mobile devices desirable, by their very nature, also poses a new set of security challenges.  Reports by research agencies in recent years show an alarming trend in mobile security threats listing as top concerns: Android malware attacks, and for the IOS platform issues with enterprise provisioning abuse and older OS versions.

These trends highlight the need for corporations to start taking seriously a mobile security strategy at the same level to which cyber criminals are planning future attacks. A mobile security strategy might involve adopting certain Mobile Security Guidelines as published by standards organizations (NIST) and Mobile OWASP project. See the references at the end of this document:

The following guidelines are a subset of Mobile Security Guidelines I pulled from various published sources with most coming from NIST. It is by no means a comprehensive list, however they can be considered as a starting point or additional considerations for an existing mobile security strategy.

1 – Understand the Mobile Enterprise Architecture

You should start with understanding and diagramming the flow from mobile application to business applications running on the back-end application server. This is a great starting point and should be done at the beginning stages, as most of the security guidelines will depend on what is known about the architecture.

  1. Is the mobile application a native application or mobile web application? Is it a cross-platform mobile application?
  2. Does the mobile application use middleware to get to the back-end API, or does it connect directly to a back-end Restful based Web Service?
  3. Does the mobile application connect to an API gateway?

2 – Diagram the network topology of how the mobile devices connect

Is the mobile device connecting to the business application servers over the cellular network or internally through a private WiFi network, or both? Does it go through a proxy or firewall? This type of information will aid in developing security requirements; help with establishing a QA security test bed and monitoring capability.

3 – Develop Mobile Application Security Requirements

At a high level, a security function must protect against unauthorized access and in many cases protect privacy and sensitive data. In most cases, building security into mobile applications is not at the top of the mind-set in the software development process. As such, these requirements should be gathered as soon as possible in the Software Development Life Cycle (SDLC). It has been my personal experience in many cases that you have to work with application software developers in adopting best security practices. So the sooner you can get that dialogue going the better. Security objectives to consider are:  Confidentiality, integrity, and availability. Can the mobile OS platform provide the security services required? How sensitive is the data you are trying to protect. Should the data be encrypted in transit, and in storage? Do you need to consider data-in-motion protection technologies?  Should an Identity and Access Management (IDAM) solution be architected as part of the mobile enterprise system? Should it include a Single Sign On functionality (SSO)? Should there be multi-factor authentication, role based or fine-grained access control? Is Federation required? Should the code be obfuscated to prevent reverse engineering?

4 – Incorporate a Mobile Device Security Policy

What types of mobile devices should be allowed to access the organization’s critical assets. Should you allow personal mobile devices, Bring Your Own Devices (BYOD’s) or consider only organization-issued or certified mobile devices to access certain resources? Should you enforce tiers of access? Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and BYOD’s by enterprise users. These technologies can remotely wipe the data or lock the password from a mobile device that has been lost or stolen. Should Enterprises consider anti malware software and OS upgrades to become certified mobiles on the network? To reduce high risk mobile devices, consider technologies that can detect and ban mobile devices that are jail broken or rooted, as these can pose the greatest risk of being compromised by hackers.

5 – Application Security Testing

According to a study performed by The Ponemon Institute, nearly 40% of 400 companies surveyed were not scanning their applications for security vulnerabilities, leaving the door wide open for cyber-attacks. This highlights the urgency for security teams to put together some sort of security vetting process to identify security vulnerabilities and validate security requirements as part of an ongoing QA security testing function. Scanning application technologies typically conduct two types of scanning methods: Static Application Security Testing (SAST) which analyzes the source code and Dynamic Application Security Testing (DAST), which sends modified HTTP requests to a running web application to exploit the application vulnerabilities. As the QA scanning process develops, it can be automated and injected into the software build process to detect security issues in the early phases of the SDLC.

6 – System Threat Model, Risk Management Process

What will typically come out of the application scanning process will be a list of security vulnerabilities found as either noise, suspect or definitive.  It will then be up to the security engineers knowing the system architecture and network topology working with the application developer to determine whether the vulnerability results in a valid threat and what risk level based on the impact of a possible security breach. Once the risk for each application is determined, it can be managed through an enterprise risk management system where vulnerabilities are tracked, fixed and the risk brought down to a more tolerable level.

7 – Consider implementing a Centralized Mobile Device Management System

Depending on the Mobile Security Policy that is in place, you may want to consider implementing a Centralized Mobile Device Management System especially when Bring Your Own Device (BYOD) mobiles are in the mix that can:

  • For mobile devices, manage certificates, security setting, profiles, etc through a directory service or administration portal.
  • Policy based management system to enforce security settings, restrictions for organization-issued, BYOD mobile devices.
  • Manage credentials for each mobile device through a Directory Service.
  • Self service automation for BYOD and Reducing overall administrative costs.
  • Control which applications are installed on organization-issued applications and check for suspect applications on BYOD mobile devices.
  • A system that can remotely wipe or lock a stolen or loss phone.
  • A system that can detect Jail-broken or rooted mobile devices.

8 – Security Information and Event Management (SIEM)

Monitor mobile device traffic to back-end business applications. Track mobile devices and critical business applications and correlate with events and log information looking for malicious activity based on threat intelligence. On some platforms it may be possible to integrate with a centralized risk management system to specifically be on alert for suspicious mobile events correlated with applications at higher risk.

References:

Leadership Essential in Cybersecurity Dynamics

/in , , , , , , , , , , , , , , , , /by

Are your C-level leaders sending a clear message about Cyber Security?

Despite the high profile security breaches making news headlines and increased attention around cyber risks, executives in the C-suites are still lacking commonality and communication of a clear goal when it comes to a cybersecurity strategy. These individuals need to work together to manage their organizational risks to help prepare, mitigate, and minimize the damage caused by cyber incidents.

Every organization needs a clear strategy and roadmap with supporting tools that protect critical assets. Read more about this topic and the crucial role the C-suite plays in the dynamics surrounding Cybersecurity.

https://securityintelligence.com/c-suite-dynamics-can-impact-the-organizations-cybersecurity/

Building an IAM Roadmap – A five step process

/in , , , , , , , , , , /by

Since 2003, our teams have been part of over 350 efforts to implement or rescue Identity and Access Management (“IAM”) projects.  Our customers, most of whom have become great friends, are from all over the US, crossing many disparate and unique industries.  In most cases, they are working to solve similar business problems and to fix or improve the same processes.

On many occasions, we started from the ground floor and had the opportunity to create a roadmap for their long-term strategy.  To those familiar with IAM capabilities, it may seem obvious what to prioritize and where to start, but let’s not be so quick to jump to what looks like an easy decision.  All IAM capabilities are not created equal.

Our job as a systems integrator is to successfully implement these complex IAM security technologies, and to ensure that our customers maximize the return on their significant IT investments.  As we help guide our customers through these decisions, this ROI is always our priority, which leads us to the topic for today.

So how, exactly, can we accomplish this?  This article is all about alignment.  Having alignment between IT and the other key stakeholders will significantly reduce the risk of your IAM projects failing and losing or wasting precious budget dollars.

How can you ensure you have correct alignment?  Here’s how our IAM Roadmap process breaks down.

Step 1 – We start by prioritizing a list of over 100 key IAM capabilities.  This list was compiled from our work over the years and is vendor agnostic.  After a brief explanation to help educate the stakeholders, we apply a ranking of low, medium or high based on their opinion on how important the organization needs a certain capability.  Typical examples of high priority capabilities are automated provisioning of accounts, self-service password reset and role recertification.

Here’s a common example of the final output

Step 2 – Once you have a high priority list to work from, we dig a little deeper into three categories of analysis.  The first category is Business Benefit – How significant is the true Business Benefit of this capability?  Is this just a shiny new IT toy or will the stakeholders see lift and leverage from adopting this functionality.  It’s critical to have your business stakeholders at the table so they can weigh in.

Step 3 – The second category is for your technical staff regarding Technical Complexity – How technically difficult will it be to configure or customize this solution?  Are there products that provide this feature and function out of the box?  Will your team be able to update and maintain the tools going forward or is this going to be way outside of their comfort zone and expertise?  Is it cost prohibitive based on the benefit?  This is where we can weigh in to help provide some context as well.

Step 4 – The third and last category is about Organizational Readiness – can the company readily adopt the capability?  Are there so many competing priorities that gaining mindshare and focus will be difficult?  Do you have the buy-in from stakeholder leadership?  Is everyone at the table truly on board with this project and these priorities?  Will they drive the effort through their organizations?

Step 5 – Once you’ve made it through this list and conducted a robust debate and Q&A with these three key questions, it’s time to score and rank the results.  Amazingly you will see a handful of capabilities that float to the top where the Business Benefit is high, the Technical Complexity is low and the Organizational Readiness is high.  After a short review of the results with some discussion and debate, a solid scope of high priority capabilities emerge as candidates for the first one or two phases of a successful program.

The next step is to choose a product that can fulfill these priorities, and then you are off and running.  The advantage you have is that your stakeholders are more educated and have bought into the process and priorities – they are aligned.  At the first sign of deviating from scope or questioning why we are including specific capabilities, you simply go back to the prior analysis and remind the team of the decision-making rationale.

Does this IAM Roadmap process guarantee a successful project or program?  Not necessarily.  But having all your stakeholders at the table and aligned provides a huge advantage and a great start.

 

7 Minutes of Terror

/0 Comments/in , , , , /by

Last month we witnessed an amazing feat of science & engineering with the landing of NASA’s Curiosity Rover on Mars. Before this could be accomplished years of preparation through innovation, design & testing had to occur. It all culminated towards what the NASA scientists and engineers at JPL call “the 7 minutes of terror” – the 7 minutes between when Curiosity entered the Mars atmosphere and when it was expected to land. Of course we know now that it was a fantastic success – but what made it so? How does an organization accomplish such a fantastic undertaking?

Well it got us here at PMG thinking; what is it that we do together with our clients that makes projects a success? We know we’re not rocket scientists, but it’s still fun to day dream & draw some interesting connections between the Curiosity mission and our own business and philosophies.  Read more