Tag Archives: Cloud computing

dilbert Data Security

3 things a medical device vendor must do for security incident response

You are VP R&D or CEO or regulatory and compliance officer at a medical device company.

Your medical devices measure something (blood sugar, urine analysis, facial anomalies, you name it…). The medical device interfaces to a mobile app that provides a User Interface and transfers patient data to a cloud application using RESTful services over HTTPS.

Sound familiar?

The Medical device-Mobile app-Cloud storage triad is a common architecture today for many diagnostic, personal well-being and remote patient monitoring indications.

We have numerous clients with the Medical device-Mobile app-Cloud storage system architecture and we help them address 4 key security issue –

  1. How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
  2. How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
  3. How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
  4. How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.

How effective is your security incident response?

The recent SANS Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.

Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.

First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees.    Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.

Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate  incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond.       This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.

Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.

3 things a medical device vendor must have for effective incident response

  1. Establish an IRT.  (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools).  Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
  2. Lead from the front. Ensure that the head of IRT reports to the CEO.   In security incident response, management needs to up front and not lead from behind.
  3. Detect in real time. Our key concern is cloud server security.    Our recommendation is to install OSSEC on your cloud servers. OSSEC sends alerts to a central server where analysis and notification can occur even if the medical device cloud server goes down or is compromised.
Tell your friends and colleagues about us. Thanks!
Share this
selling security products with fear, ignorance and online marketing

Why security defenses are a mistake

Security defenses don’t improve our understanding of the root causes of data breaches

Why is this so? Because when you defend against a data breach – you do not necessarily understand the vulnerabilities that can be exploited.

If do not understand the root causes of your vulnerabilities, how can you justify and measure the effectiveness of your defensive measures?

Let me provide you with an example.

Conventional IT security practice says that you must install a firewall in front of a server farm.

Firewalls prevent the bad guys from getting in. They don’t prevent sensitive data assets from leaving your network during a data breach.

If you have a dozen servers, running Ubuntu 12.04 with the latest patches, hardened and only serving responses to requests on SSH and HTTPS services not only is there no added value in a firewall but installing and maintaining a firewall will be a waste of money that doesn’t defend against a data breach.

First of all – defenses are by definition, not a means of improving our understanding of strategic threats. Think about the Maginot Line in WWI or the Bar-Lev line in 1973. Network and application security products that are used to defend the organization are rather poor at helping us understand and reduce the operational risk of insecure software.

Second of all – it’s hard to keep up. Security defense products have much longer product development life cycles then the people who develop day zero exploits. The battle is also extremely asymmetric – as it costs millions to develop a good application firewall that can mitigate an attack that was developed at the cost of three man months and a few Ubuntu workstations. Security signatures (even if updated frequently) used by products such as firewalls, IPS and black-box application security are no match for fast moving, application-specific source code vulnerabilities exploited by attackers and contractors.

Remember – that’s your source code, not Microsoft.

Third – threats are evolving rapidly. Current defense in depth strategy is to deploy multiple tools at the network perimeter such as firewalls, intrusion prevention and malicious content filtering. Although content inspection technologies such as DPI and DLP are now available, current focus is primarily on the network, despite the fact that the majority of attacks are on the data – customer data and intellectual property.

The location of the data has also become less specific as the notion of trusted systems inside a hard perimeter has practically disappeared with the proliferation of cloud services, Web 2.0 services, SSL VPN and convergence of almost all application transport to HTTP.

In summary – before handing over a PO to your local information security integrator – I strongly suggest a systematic threat analysis of your systems. After you have prioritized set of countermeasures – you’ll be buying, but not necessarily what he’s selling.

Tell your friends and colleagues about us. Thanks!
Share this
Bridging the security IT gap with BI

How to use BI to improve healthcare IT security


Information technology
management is about executing predictable business processes.

Information Security Management is about reducing the impact of unpredictable attacks to  your  healthcare provider organization.

Once we put it this way – it’s clear that IT and security and compliance professionals, as dedicated as they are to their particular missions – do not have common business objectives and key results. This is why we have so many software security issues – we have software that is developed and implemented with disregard to best practice security.

In order to bridge the gap – healthcare provider IT and security professionals need to adopt a common goal and a common language – a language  of customer-centric threat modelling

Typically, when a healthcare provider ( whether a hospital, HMO or primary care provider) needs  software application,  an IT consultant will do a system analysis starting with business requirements and then proceed to propose a solution to buy or build an application and deploy it.

Similarly, when the information security group needs an anti-virus or firewall, security consultants  make requirements based on the current risk profile of the healthcare provider, test products, and proceed to buy and deploy or subscribe and deploy the new anti-virus or firewall solution.

The problem is that the two activities never work together – as result, we get islands of software applications that are not integrated with the company information security and compliance portfolio and we get information security technologies that are unaware of the applications and in a worst case scenario – get in the way of business productivity.

Michael Koploy of Software Advice explains well on how BI (business intelligence, once the domain of IT expert consultants) is now highly accessible technology in his article 4 Steps to Creating Effective BI Teams.

Business intelligence–the use of sophisticated software to analyze complex data–is no longer the domain of a centralized group of IT staff or advanced data analysts. Today, powerful and Web-based BI tools are accessible to a wide range of business users.

BI is everywhere, and it’s everyone’s job. But with this proliferation comes new challenges. Teams of BI users today often lack the structure, guidance and leadership to effectively mine data. In this article, I’ll share four steps to establish guidelines, organize teams, delegate data management and allow the success of the BI team to permeate and drive innovation throughout the business.

I agree with Michael.

By using BI – we can explore vulnerabilities in business processes and bring the information back to healthcare IT and security management in a constructive way and start building that common language between healthcare IT  and healthcare security management that is so essential to protecting patient health records.

Tell your friends and colleagues about us. Thanks!
Share this
selling security products with fear, ignorance and online marketing

The mistakes you will make on your next cloud project

Are you considering cloud security in the abstract or cloud security in your software?

Looking at cloud security issues in the abstract, we see 4 areas of concern:

  1. Mobility of Resources and multi-tenancy
  2. Identity and access management
  3. Data protection
  4. Incident response and assessment

When choosing a cloud solution for your business application, it is easy to get dragged into a low level engineering discussion of these issues.

However, we don’t implement things in the abstract; we implement real-life applications in the cloud.

Our decisions on implementing security countermeasures in the cloud should actually not be a function of  4 abstract security concerns but of  business and security management decisions:

  1. The cloud service model you choose. This is a business decision constrained by software engineering factors.
  2. How you detect and mitigate your application vulnerabilities. This is a security management decision.

The cloud service model is supremely important and is closely tied to your business requirements.  If you are a business unit manager at healthcare provider looking to implement a private social network for healthcare, you will be looking at SaaS alternatives.  If you are a VP engineering at a company developing business analytics, you will be considering PaaS or IaaS service models where the language support is one of your key drivers. If you are a Java shop and the BigTable key-value data model used by Google App Engine appeals to you, then Google App Engine may be your best fit.  On the other hand, if you are a Ruby shop, you may want to consider Heroku.

Once you choose a cloud service model, you should spend as much time as possible doing threat modeling of your software and estimating your value at risk.

Since buggy software is insecure software, and since most bugs are baked into the design, and since it’s cheaper to fix bugs in software at the beginning of the software life cycle – it’s about getting the software architecture right and then doing the implementation well and not about bolting on some third-party application security firewall rented out to you by your cloud service provider.

Service models

Mobility of Resources and multi-tenancy is are a core requirement for a cloud service provider. If he’s doing a good job, it’s his first order of business,  not your first order of concern.

Regarding  Incident response and assessment, if your cloud provider is proactive, that is a very good sign that Incident response and assessment will be handled properly.  If he waits for you to tell him that there is a hacking issue on your server, then it’s time to start looking for a different cloud service provider.

Identity and access management are part of your application. The architecture and deployment of your application is influenced by your choice of service model but it’s still your code running in the cloud.

Data protection is either some, not or all your responsibility depending on the service model and your software applications. This is why we need to do threat analysis on the software and consider data protection as one of the areas of concern.

Choosing the right cloud service model

The market is shaking out right now and in any given segment there are only 2 or 3 players you should be considering.

SaaS

High integration, low flexibility, high vendor lock-in Meant for end-users. Think SF.com

PaaS

Less integration, mid flexibility, medium vendor lock-in Meant for application developers. Think Google App Engine, Appforce.com, heroku, Azure

IaaS

No integration, total flexibility, low vendor lock-in. Good for engineers. Think Amazon WS, Rackspace Cloud

2 management mistakes you will probably make on your next cloud project

  1. Overengineering defense in depth and
  2. Ignoring or mis-estimating your application software threat surface

This is a situation we often see with product development companies that develop a cloud service using IaaS (infrastructure as a Service) where they  implement too many controls in too many layers and ignore or minimize  the threat surface of the application software for security and compliance breaches.

Overengineering defense in depth

You can over-engineer your  defense in depth strategy and implement Firewall, load balancers, IPS in multiple layers in the cloud: in the WAN, on the LAN, in the virtual machines  and in hardware appliances.  The more layers you have, the more things that can go wrong. You will be more vulnerable instead  of being more secure and you will have to deal with half a dozen new issues that you created your self:

  1. Patch management is hard
  2. Different management systems, since each layer has it’s own management
  3. Different administrators, since each management system has it’s own admin
  4. Visibility for the end user customer is impossible
  5. Almost impossible to audit

What things can go wrong when you ignore application threat surfaces?

Lots. DB exploits Connector vulnerabilities Shell script vulnerabilities SQL injection DDOS, information disclosure by malicious insiders.

Typical Web 2.0 attack scenarios

Here are a few you should be thinking about:

  1. Any kind of code injection
  2. Server or client returns invalid HTML
  3. Pages that contain dead links
  4. HTML forms that don’t match field types expected by controllers
  5. Client side code that makes bad assumptions about AJAX services
  6. Servers  that may attempt to execute invalid SQL queries
  7. Improper marshaling/un-marshaling between DB server to Web server DB server to application tier Web server to browser

Typical Web 2.0 vulnerabilities

Here are a few you should be thinking about:

  • Running a number of heterogeneous stacks guarantees too much chewing gum
  • Mixing  languages and frameworks may be problematic causing typing and interface issues.
  • PHP, Ruby, Python Flexibility, no static type guarantees
  • C#, Java Static typed, but only at Web server
  • Code complexity that increases application threat surfaces.
  • Redundant code on servers and clients
  • Redundant data on servers and clients

Summary

At the end of the day, the Cloud Security Control model looks great, but it doesn’t mitigate core vulnerabilities in your software or tendencies by system architects to over engineer. Once you choose the right service model and vendor, you should put aside the cloud security reference models and focus on hardening your own application software –

Remember – it’s your code that will be running in someone elses cloud.

Tell your friends and colleagues about us. Thanks!
Share this

Clinical trials in the cloud

Ben Baumann from Akaza and Open Clinica fame, recently blogged about clinical trials in the cloud.  Ben is pitching the relatively new offering from Akaza called Open Clinica Optimized hosting that offers quick startup using validated Open Clinica instances and resources on-demand on a SAS-70 compliant platform.

As Ben noted that in the clinical research field, putting together such an offering is not trivial. Open Clinica is the worlds fastest growing clinical trials software with an interesting Open Source business model of community-supported Open Source and revenue from enterprise licensing, cloud services and training.

Software Associates specializes in helping medical device vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.  We have been working with a regulatory affairs consulting client for over 3 years now, using the Open Clinica application for managing  large multi-center, international clinical trials using Rackspace hosting and more recently using Rackspace Cloud.

I can attest that running multi-center clinical trails in the cloud is neither for the faint of heart nor weak of stomach.  Past the security, compliance and regulatory issues – there is also the issue of performance.

Although resources are instantly scalable on-demand in the cloud, resources are not a substitute for secure software that runs fast.

As I noted in a previous essay “The connection between application performance and security in the cloud“, slow applications require more hardware, more database replication, more load-balancing and more firewalls. More is not always better, and more layers of infrastructure increase the threat surface of the application with more attack points on the interfaces and more things that can go wrong during software updates and system maintenance.

If there is a design or implementation flaw in a cloud application for clinical trials management that results in the front-end Web server making 10,000 round trips to the back-end database server to render a matrix of 100 subjects, then throwing more hardware at the application will be a fruitless exercise.

If we do a threat analysis on the system, we can see that our No. 1 attacker is the software itself.

In that case, the application software designers have to go back to the drawing board and redesign the software and get that number down to 1 or 2 round trips.

The effort will be well worth it in your next bill from your cloud service provider.

 

Tell your friends and colleagues about us. Thanks!
Share this

The valley of death between IT and information security

IT is about executing predictable business processes.

Security is about reducing the impact of unpredictable attacks to a your organization.

In order ot bridge the chasm – IT and security need to adopt a common goal and a common language – a language  of customer-centric threat modelling

Typically, when a company ( business unit, department or manager) needs a line of business software application, IT staffers will do a system analysis starting with business requirements and then proceed to buy or build an application and deploy it.

Similarly, when the information security group needs an anti-virus or firewall, security staffers will make some requirements, test products, and proceed to buy and deploy or subscribe and deploy the new anti-virus or firewall solution.

Things have changed – both in the IT world and in the security world.

Web 2.0 SaaS (software as a service) offerings (or  Web applications in PHP that the CEO’s niece can whip together in a week…) often replace those old structured systems development methodologies. There are of course,  good things about not having to develop a design (like not coming down with an advanced case of analysis paralysis) and iterating quickly to a better product, but the downside of not developing software according to a structured systems design methodology is buggy software.

Buggy software is insecure software. The response to buggy, insecure software is generally doing nothing or installing a product that is a security countermeasure for the vulnerability  (for example, buying a database security solution) instead of fixing the SQL injection vulnerability in the code itself.   Then there is lip-service to so called security development methodologies which despite their intrinsic value, are often too detailed for practioners to follow), that are not a replacement for a serious look at business requirements followed by a structured process of implementation.

There is a fundamental divide, a metaphorical valley of death of  mentality and skill sets between IT and security professionals.

  • IT is about executing predictable business processes.
  • Security is about reducing the impact of unpredictable attacks.

IT’s “best practice” security in 2011 is  firewall/IPS/AV.  Faced with unconventional threats  (for example a combination of trusted contractors exploiting defective software applications, hacktivists or competitors mounting APT attacks behind the lines), IT management  tend to seek a vendor-proposed, one-size-fits-all “solution” instead of performing a first principles threat analysis and discovering  that the problem has nothing to do with malware on the network and everything to do with software defects that may kill customers.

Threat modeling and analysis is the antithesis of installing a firewall, anti-virus or IPS.

Analyzing the impact of attacks requires hard work, hard data collection and hard analysis.  It’s not a sexy, fun to use, feel-good application like Windows Media Player.   Risk analysis  may yield results that are not career enhancing, and as  the threats  get deeper and wider  with  bigger and more complex systems – so the IT security valley of death deepens and gets more untraversable.

There is a joke about systems programmers – they have heard that there are real users out there, actually running applications on their systems – but they know it’s only an urban legend. Like any joke, it has a grain of truth. IT and security are primarily systems and procedures-oriented instead of  customer-safety oriented.

Truly – the essence of security is protecting the people who use a company’s products and services. What utility is there in running 24×7 systems that leak 4 million credit cards or developing embedded medical devices that may kill patients?

Clearly – the challenge of running a profitable company that values customer protection must be shouldered by IT and security teams alike.

Around this common challenge, I  propose that IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling – threats, vulnerabilities, attackers, entry points, assets and security countermeasures.  This may be the best or even only way for IT and security  to traverse the valley of death successfully.

Tell your friends and colleagues about us. Thanks!
Share this

Apps vs. the Web, enemy or friend?

Saw this item on Gigaom.

George Colony, the chairman and CEO of Forrester Research, re-ignited a minor firestorm recently, with a presentation at the LeWeb conference in which he argued that the web is dead, and being replaced by the app economy — with mobile and smartphone apps that leverage the cloud or other services rather than the open web.

I have written here and here about the close correlation between Web application security and Web performance.

I know that Mr. Colony has sparked some strong sentiment in the community, in particular from Dave Winer:

If I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub. How nice your bathtub is. Try building a continent around it.

Of course, that is neither true nor relevant.

Many apps are indeed well connected, and the apps that are not wired-in, don’t have to be wired; the app is simply doing something useful for the individual consumer (like iAnnotate displaying a PDF file of music on a iPad or Android tablet).

iAnnotate turns your iPad into a world-class productivity tool for reading, annotating, organizing, and sending PDF files. Join the 100,000s of users who turn to iAnnotate for their PDF annotating needs. We designed iAnnotate to suit your individual workflow.

I became even more cognizant that apps may overtake the open Web over the past 2 weeks when Google Apps was going through some rough spots and it was almost impossible to read email to  software.co.il or access or calendars…except from our Android tablets and Nexus S smartphones.   Chrome and Google Apps was almost useless but Android devices just chugged on.

There is a good reason why apps are overtaking the open browser-based web.

They are simply more accessible, easier to use and faster.

This is no surprise as I noted last year:

The current rich Web 2.0 application development and execution model is broken.

Consider that a Web 2.0 application has to serve browsers and smart phones. It’s based on a heterogeneous server stack with 5-7 layers (database, database connectors, middleware, scripting languages like PHP, Java and C#, application servers, web servers, caching servers and proxy servers.  On the client-side there is an additional  heterogeneous stack of HTML, XML, Javascript, CSS and Flash.

On the server-side, we have

  • 2-5 languages (PHP, SQL, tcsh, Java, C/C++, PL/SQL)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Server-side database management (MySQL, MS SQL Server, Oracle, PostgreSQL)

On the client side, we have

  • 2-5 languages ((Javascript, XML, HTML, CSS, Java, ActionScript)
  • Lots of interface methods (hidden fields, query strings, JSON)
  • Local data storage – often duplicating session and application data stored on the server data tier.

A minimum of 2 languages on the server side (PHP, SQL) and 3 on the client side (Javascript, HTML, CSS) turns developers into frequent searchers for answers on the Internet (many of which are incorrect)  driving up the frequency of software defects relative to a single language development platform where the development team has a better chance of attaining maturity and proficiency. More bugs means more security vulnerabilities.

More bugs in this complex, broken execution stack means more things will go wrong and as devices and apps are almost universally accessible now; it means that customers like you and me will not tolerate 2 weeks of downtime from a Web 2.0 service provider.  If we have the alternative to use an app on a tablet  device, we will take that alternative and not look back.

Tell your friends and colleagues about us. Thanks!
Share this
Manuela Arcuri

Monica Belluci and Security

Trends –  security and movie stars, Manuela Arcuri and  Monica Bellucci, Verisign and Mcafee.

Information security and  risk analysis is complex stuff, with multiple dimensions  of people, software, performance, management, technology, assets, threats, vulnerabilities and control relationships.  This is why it’s hard to sell security to organizations. But, information security is also a lot like fashion with cyclical hype and theater: today – , HIPAA, iOS and Android security,  yesterday – Sarbanes-Oxley, federated identity management, data loss protection and application security firewalls.

Back in 2007,  I thought we might a return to the Age of Reason, where rational risk management replaces blind compliance check lists – I thought that this could happen  for 2 reasons:

  1. Compliance projects  can have good business value, if you focus on improving the product and it’s delivery.
  2.  Security is like fashion – both are cyclical industries, the wheel can also turn around in the right direction.

HIPAA compliance is a minimum but not sufficient requirement for product and process improvement.

Healthcare companies and medical device vendors that do HIPAA compliance projects, may be paying a steep price for HIPAA compliance without necessarily getting a return on their investment by improving the core features and functionality of their products and service offerings.

Compliance driving improvements in products and services is good for business, not just a mantra from Mcafee.

It could happen, but then again, maybe not. Look at the trends. Taking a sample of articles published in 2011 on the  eSecurityPlanet Web site we see that  mobile devices and cloud services lead the list, followed by IT security with healthcare closing the top 15. I guess cost-effective compliance is a lot less interesting than Android security.

  1. iOS vs. Android Security: And the Winner Is?
  2. 5  iOS 5 Enterprise Security Considerations – You can’t keep Apple out of the enterprise anymore so it’s best to figure out the most secure way to embrace it, writes Dan Croft of Mission Critical Wireless.
  3. PlayBook Tops in Tablet Security – Recent price reductions may mean more Blackberry Playbook tablets entering your organization, but that may not be such a bad thing for IT security teams.
  4. Android Security Becoming an Issue – As the Android mobile platform gains market share, it also garners a lot of interest from cyber crooks as well as IT security vendors.
  5. Which Browser is the Most Secure? – The ‘most hostile’ one, say researchers at Accuvant Labs.
  6. How to Prevent Employees from Stealing Your Intellectual Property -It’s the employee with the sticky hands that is the easiest and cheapest to thwart.
  7. Security Spend Outpacing the Rest of IT – High profile breaches and mobile devices are driving IT security spending.
  8. Public Cloud Keys Too Easy to Find -If you put the keys to your cloud infrastructure in plain sight, don’t be surprised if you get hacked.
  9. Zeus (Still) Wants Your Wallet – The antivirus community has failed to figure out this able and persistent piece of malware. It’s as simple as that.
  10. Spear Phishing Quickly Coming of Age – Even the security giants are not immune from this sophisticated and growing form of attack, writes Jovi Bepinosa Umawing of GFI Software.
  11. Penetration Testing Shows Unlikely Vulnerabilities – Enterprises need to dig deeper than just automated scanning to find the really interesting and dangerous cyber security flaws.
  12. Bank Fraud Still Costing Plenty – Bank fraud is and will continue to be an expensive problem.
  13. Do IT Security Tools Really Make You Safer? – Yet another suite of tools for IT security folks to administer and manage can actually have the opposite effect.
  14. Siege Warfare in the Cyber Age – In one the unlikeliest turn of events brought about by technology, it looks like Middle Ages’ siege warfare may be making a comeback, writes Gunter Ollmann of Damballa.
  15. Healthcare Breaches Getting Costlier – And it’s not just dollars and cents that are on the line – reputations are on the line, writes Geoff Webb of Credant Technologies.
Tell your friends and colleagues about us. Thanks!
Share this

Security is in the cracks

Yesterday I spent most of the day re-installing one of the  workstation in the office with Ubuntu 11.10. I like what I saw, but the Unity interface is not my cup of tea so I installed Gnome – what they call Classic Ubuntu.

In principle I shut down as many operating services as I can – especially those that call out and/or listen on the Internet but this is supposed to be a development machine with access to our private git repository and sending out email via a Postfix relay.

On our own  small scale of a lab with 6-7 machines for testing network and software security of customer applications, I  got  thinking that most system vulnerabilities live in the cracks of system integration of components and packaged software while most of the industry’s efforts in software security are directed towards new software implementations.

If you are preparing to implement a packaged application for financial management, CRM, data mining or ERP something in the back of your mind probably says that the vendor’s development organization is probably not a lot different than yours (although you hope they’ve thought through the security issues first)..

Here are a 2 ideas to help find the crud in the cracks:

  • Inspect and penetration-test the system; assess infrastructure components, database interfaces and Web applications for vulnerabilities using The Software Associates 6 step Business threat analysis methodology
  • You need to identify fault-prone modules in your particular operation and evaluate those modules with the most impact on system reliability and downtime.
Tell your friends and colleagues about us. Thanks!
Share this

Cloud security assessment

A customer case study – cloud security assessment

Faced with a steep bill for securing a new cloud application, a client asked us to help find a way to reduce their risk exposure at the lowest possible cost. By using the Business Threat Modeling methodology and PTA (Practical Threat Analysis) software, we were able to build a risk mitigation plan that mitigated 80% of the total risk exposure in dollars at half the original security budget proposed by the vendor.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this