Tag Archives: Open Source

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

Practical security management for startups

We normally associate the term “small business” or SME (small to medium sized enterprise) with commercial operations that buy and sell, manufacture products or provide services – lawyers, plumbers, accountants, web developers etc…

However – there is an important class of small business operations that is often overlooked when it comes to information security and is the technology startup.   A high tech startup is an SME by all definitions – usually less than 50 employees but it doesn’t buy and sell and neither does it provide professional services.   Unlike other small businesses, a high tech startup is almost purely focussed on product research and development. Almost all startups have a very high percentage of software development. Even if the startup develops hardware – there is still a strong software development focus.

Intuitively – one would say that a primary concern for a startup is IP (intellectual property) protection and that starts with protecting source code.

Counter-intuitively this is not true. There are two basic reasons why source code leakage is not necessarily a major threat to a startup:

1) If the startup uses FOSS (free open source software), there is nothing to hide.  This is not strictly speaking correct – since the actual application developed using FOSS has immense value to the startup and may often involve proprietary closed  source code as well.

2) A more significant reason that source code leakage is of secondary importance is that a startup IP is invariably based on a combination of three components:    Domain expertise, implementation know-how and the implementation itself (the software source code).   The first two factors – domain expertise and  implementation know-how are crucial to successful execution.

The question of how to protect IP still remains on the table but it now is reshaped into a more specific question of how best to prioritize security countermeasures to protect the startup’s domain expertise and  implementation know-how.  Prioritization is of crucial importance here, since startups by definition do not generate revenue and have little money to spend on luxuries like data loss prevention (DLP ) technologies.

Software Associates works exclusively with technology and medical device developers and I’d like to suggest a few simple guidelines for getting the most security for your money:

The startup management needs to know how much their information security measures will cost and how it helps them run the business. Business Threat Modeling (TM) is a practical way for a manager to assess the operational risk for the startup in dollars and cents. The advantages of the business threat modeling methodology are:

  • Threat modeling places the focus on asset management and Value at Risk reduction before acquisition of information and security technologies.
  • Threat modeling helps select  the right countermeasures often prioritizing monitoring before active data loss prevention (for example)
  • Threat  modeling, when done right, quantifies risk in dollar terms. This is particularly important when reporting back to the investors on exposure to data loss of IP.
  • Threat modeling helps justify investments in security, compliance and risk management to the management board – simply because it puts everything into financial values – the value at risk and cost of the security portfolio.

These are similar objectives to GRC (Governance, risk and compliance) systems.

The problem with most GRC (governance, risk and compliance) and ERM (enterprise risk management) systems is that they don’t calculate risk, they make you work hard and they’re not that easy to use.

I think that we can all agree that the last thing that a hi-tech startup needs is a system to manage GRC activities when they’re working to make the next investor milestone.

Startup management needs a simple security management approach that they can deploy themselves, perhaps assisted with some professional consulting to help them get started and get a good feel for their exposure to security and compliance issues.

How does a practical security management methodology like this work? Well – it works by using common language of threat modeling.

You own assets – for example, expensive diamond jewelry stored at home. These assets have a dollar value.

Your asset has vulnerabilities – since you live on the ground floor and your friendly German Shepherd knows where the bedroom is and will happily show anyone around the house.

The key threat to the asset is that an attacker may break in through the ground floor windows.

The countermeasures are bars for the windows, an alarm system and training your dog to be a bit less friendly around strangers with ski-masks.

Using countermeasure costs, asset value, threat probability of occurrence and damage levels, we calculate Value at Risk in financial terms, and propose an prioritized, cost-effective risk mitigation plan.

That’s it – adopt a language with 4 words and you’re on a good start to practical security management for your high tech startup.

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

Using DLP to protect your source code

Dec 10, 2010.

Sergey Aleynikov, a 40-year-old former Goldman Sachs programmer, was found guilty on Friday by a federal jury in Manhattan of stealing proprietary source code from the bank’s high-frequency trading platform. He was convicted on two counts — theft of trade secrets and transportation of stolen property — and faces up to 10 years in prison.

Mr. Aleynikov’s arrest in 2009 drew attention to a business that had been little known outside Wall Street — high-frequency trading, which uses complex computer algorithms to make lightning-fast trades to exploit tiny discrepancies in price. Such trading has become an increasingly important source of revenue for Wall Street firms and hedge funds, and those companies fiercely protect the code underpinning their trading strategies.

See full story on the Goldman Sachs source code theft incident

If you have proprietary algorithms, it can and may be happening to you. Consider three threat scenarios for software assets:

1. Source code  theft by employees

Source code theft by employees can be a major ethical issue that requires good management but also good detection. Designing, developing and deploying successful software is complex business, but unfortunately, most companies don’t know whether or not their source code is leaving their network with some proprietary algorithms. See the story about Chinese source code theft.

The stories of losing source code and having it posted on the Net are fairly common – remember  Windows NT source code and Mainsoft?.  We’ve found, from work with software developers, that many source code leaks are never reported. Frightengly, companies usually have no idea how the source code got out in the first place and call in consultants after the event to detect the origin of the leak .

In order to respond quickly to a suspected disclosure of company IP/source code, it’s crucial to be doing real time detection which is far more important than trying to prevent unauthorized disclosure altogether.

2. Source code leakage from outsourcing

In many cases,  source code leaks from a network run by an outsourcing service provider or from a team of outsourcing contractors connected via a VPN. However, if companies cannot detect problems in their own networks, they are unlikely to find them in others. The result is an outsourcing relationship built on a shaky foundation with no independent monitoring capability to enforce non-disclosure agreements.

This points at a wider problem for software developers everywhere. Whether you collaborate with a partner on development or outsource an entire project, you expose sensitive software and intellectual assets to people people with limited allegiance to your firm.

3. Misuse of Open Source software

This is probably worth an entire article in it’s own right but most developers today incorporate Free Open Source software into their projects. The Open Source license, if it’s GPL for example, may be infectious in the sense that if the GPL requires disclosure of sources, then incorporating GPL-licensed code into your project may require you to do the same (read about copy-left licenses).  In that case – you should start by establishing a policy for using Open Source licenses and monitor usage of Open Source code.

How can DLP (data loss prevention) help you protect your source code?

Data loss prevention (or in this case data loss detection) of software source code is based on three key concepts

  1. A direct approach – prevent valuable software assets from getting out, unlike indirect methods that focus on preventing unwanted users from getting in. Conventional IT security takes an indirect approach by focusing on controlling user and system  behavior through access control and authentication. This indirect method places a heavy burden on your security staff and does not scale well. It won’t get the job done.
  2. Real-time flow monitoring – of software assets over all channels. Since almost everything tunnels over http today, you have to worry about back-channels and not just email
  3. Network audit – DLP should be used in a detection capacity to detect upticks in unusual activity; for example unusually large FTP or SCP file transfers may be a pre-cursor of an employee getting ready to leave the company with large quantities of your source code and proprietary algorithms

When deploying DLP for source code protection, consider technical and  business requirements.

Technical requirements. Commercial DLP products include pre-built fingerprints for identifying C/C++C# source code.  A more substantial requirement  is that the DLP solution you choose should use network DLP technology that is bi-directional on all channels – two possible candidates are Websense DLP and Fidelis Security Systems XPS.

Business requirements start with management commitment to the project, and policy for use of Open Source code and use of code and non-disclosure by contractors.

And finally, a post like this would not be complete without the requisite 7 step checklist:

A 7 Step check list for source code protection for the information security team

  1. Acknowledge that black holes exist (for example: no policy for Open Source licensed code, unclear policy for use of company IP in contractor software development). Fix it by writing the appropriate policies and implementing them.
  2. Get your VP Technologies to agree and budget money.
  3. Identify your company’s business needs for source code protection. Some senior executives don’t care what you do – they only care about sleeping well at night. The more you know about their issues the easier it is to sell them. Don’t improvise.
  4. If you’re not using bi-directional network DLP today, call a DLP vendor on Wednesday and ask them to come into the office on Monday with a box.
  5. Give them one hour to set up on a production network segment. Try a few of your favorite cases; trap a webmail with some top-secret project keywords, fingerprint a SQL query from your data model, steal some C# source code from your own system and upload to github.com
  6. Allocate one day for a hands-on evaluation and have the vendor in a week later to discuss results.
  7. Be patient. Be prepared to refine the rules.

Using DLP technology to monitor movement of source code can be a rewarding exercise in terms of protecting company IP and reputation, however it is not a trivial task. Just remember:

It’s kinda fun to do the impossible

Walt Disney

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

DimDim acquired by salesforce.com

Got back from my Friday morning bike ride and popped open my Inbox. Lo and behold – exciting M&A news first thing in the day.

Dear Enterprise Customer::

As you may have already heard, Dimdim has been acquired by salesforce.com.  We realize you may be wondering what this means for you.

While your Dimdim Enterprise service will remain fully operational during the life of your current contract, we will discontinue the service on the date the contract expires and will not be offering any renewals or extensions.

Pursuant to the Hosted Enterprise Agreement (the “Agreement”) between you (“You”) and Dimdim, Inc. (“Dimdim”) governing the provision and use of Dimdim’s Services (as defined under the Agreement), Dimdim is hereby exercising its option not to renew the Agreement after the expiration of the current term (either the Initial Term or current Renewal Term, as applicable, and referred to herein as the “Term”). For clarity, the Agreement shall not automatically renew nor may the Term be extended at Your request. Nothing herein is intended by Dimdim to diminish or waive the rights or obligations of either party under the Agreement until the expiration of the Term. Following the expiration of the Term, except for any confidentiality obligations under the Agreement that expressly survive termination of the Agreement, neither You nor Dimdim shall have any further rights or obligations of any kind under the Agreement, including the right to access or receive any Software, Services or Technical Support as defined therein.

I have always thought that client-less Web conferencing was a great idea and DimDim was pretty good software, although the Open Source part of it turned out to be marketing spin (they never really stood behind the project).  Although the opportunity for leveraging an innovative Open Source project seems to have gone by the wayside, perhaps the salesforce.com acquisition opens a new space of business opportunities for Facebook style applications with Web conferencing and collaboration on the SF.com platform .

Time will tell.

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

The 7 deadly sins of software security

Companies spend millions on compliance, but proprietary assets are still getting ripped off by insiders and hackers who compromise buggy, poor-designed applications. Here are 7 software development mistakes you don’t want to make in 2011.

7. Don’t KISS

If my experience is any indication – the software industry as a whole is wasting hundreds of millions of dollars a year by not Keeping It Simple. For example, complex technologies like Java J2EE are not warranted for the majority of Web applications. In my experience PHP is simpler to program and maintain, and scales well at a reasonable price – witness the millions of Yahoo pages are served by PHP each day. Lack of KISS is the main reason for high-costs, late schedules, failed projects and unsecure software that no one can maintain. When a programmer uses a component and doesn’t know it works (see EJBQL and CMP 2.0) and has to shlep around a lot of piping (look at an Eclipse project for a 3 tier J2EE project) then the energies go into implementation instead of thinking about code threats. It’s sort of like Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Seems to me that the industry is trading off simpler, reliable and secure programming for fashion and features (J2EE,XP…)

6. Mismanage software development

The classic The Mythical Man-Month, written 20 years ago said that projects based on per-unit “man-months” usually dont work due to the unique nature of software development. The difference in productivity between the best programmer and an average guy is 100x. This means that 5 nwe college grads are inferior to solid programmer who knows what she’s doing. You are always better off with a few talented programmers than a large cast of average developers, a) because of individual productivity differentials and b) because smaller groups are always more effective.

This general observation is relevant to our case since the average developer construes O/S security with applying patches and application security with having an application firewall. Truth be told, it only takes one page of best practices for a Web application programmer not to allow SQL injection, long URLs, arbitrarily long input strings or directory traversal.

5. Take a wrong turn with outsourcing

Don’t outsource something just because it’s too hard to understand or you’re in a rush to market. A server clustering system offered by a major vendor was ported a while back to Linux by a team in India. The Indian market was booming and job loyalty was low, like Israel and Silicon Valley in the 90’s. In addition, due to transportation and cultural issues the work day was a fixed 8 hours not a “finish before you go home/never break the build” philosophy. The software was ported and is being delivered to customers with cryptic documentation, patch on patch on patch, multiple options to perform the same function (only one of which may be right, so the customer has to guess because documentation is unclear) and brittle functionality – a small change in configuration files can break the cluster.

Brittleness and poor documentation force the user to rely on strict manual operational procedures which depend on people which creates operational vulnerability.

4. Promote or hire the wrong people

I could write a book about this one. One common case is the excellent technologist who is promoted (desiring the job) into a managerial spot. He doesn’t have the people skills, won’t admit failure and can’t visualize going back to his old programmer slot. Another common case is hiring an ex-military guy to run a young engineering team. Six months later after the team has quit, your CEO will realize that you can’t hand orders to programmers like soldiers and you can’t flirt with the lady engineers and ask them to fetch the boss coffee.

The people who manage the teams have to have the art of software building and people building.

3. Decide based on religious beliefs

I know a company that decided on Open Source and Linux, going with a leading commercial distribution and a large systems integrator believing that the combination of Open Source and big-name vendors would guarantee success. The integrator’s skill set was primarily Windows, the distro vendor could care less about the fundamental flaws in the client’s design,and the company didnt have enough inhouse know-how of tool chain and Linux and couldn’t properly audit the progress and assess the problems of his contractor. Fortunately the project failed. I hate to think what would have happened if they would have succeeded in shipping the product – a SOHO security appliance with a Web interface for remote configuration.

The project spec must fit the system requirements; dont convert the system requirements to your religious beliefs.

2. Ignore internal system threats

Sales people know that sometimes their biggest competitors in closing a deal with a customer are people inside the company. For developers, this means that the programmer and her boss need to do a threat analysis from day 1 on the system taking into account backdoors, possible misuse, hard-coded parameters that can be forgotten or hacked later on and so forth. Temporary ftp servers for file transfer turn into permanent arrangements and vulnerability.

The team has to think about who will install, integrate and maintain the system even before considering operational issues.

1. Permit weak passwords

Threats such as worms get top PR but dont miss a basic IT mistake: weak authentication or bad passwords. Common password vulnerabilities include weak passwords (birthdays),publicly displayed passwords on Post-its, and Intranet and administrator passwords that the whole company knows. At my last company, people thought I had a great memory while in truth, just by working with the person; I could quickly and correctly guess the password to their workstation or servers. Later, after the team delivers the software, an external system integrator is often involved for installation at customer sites.

It is the responsibility of the developers to ensure that the system integrator will NOT be able to install the file transfer process between the AS400 and the billing system with anonymous ftp. I’m a fan of passphrases, I think they’re easier to remember and harder to crack but at the end of the day, passwords or passphrases need to be treated like cash. If you must, write them down on a piece of paper and save it your wallet. Dont store them on your Palm or save a file called system_passwords.xls in the MyDocuments folder of a PC in the computer room.

What should you do?

The software development environment of 20 years ago is radically different today. Development tools are free, hardware is almost free (think about those $100k Sun Enterprise 450 boxes and $500 Sun Ethernet NICS) and programming talent is a global resource. Its so easy to do things today but thats precisely the problem.
A development team can do but there is no replacement for a program/team manager that manages and directs the team away from the mistakes consistently.

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

Open Source Security Testing

Pete Herzog, Founder of ISECOM, will be discussing the revised Open Source Security Testing Methodology Manual (OSSTMM v3) and how it applies to web application security today (10-13-2010) in Raleigh, NC.

I’m not sure exactly if this project really qualifies as Open Source – since the license is not specified.  As a methodology and not a piece of software – I would have expected to see a Creative Commons License.

Tag lines aside – the OSSTMM is a peer-reviewed methodology for performing security tests and metrics, and the test cases are divided into five channels (sections) which collectively test: information and data controls, personnel security awareness levels, fraud and social engineering control levels, computer and telecommunications networks, wireless devices, mobile devices, physical security access controls, security processes, and physical locations such as buildings, perimeters, and military bases.

Pete rarely gets to the US, so this is a unique opportunity for security professionals to have an open discussion with him about trust-based security models and how to apply sound logic to securing and testing web application.

Christoph Baumgartner, CEO of OneConsult GmbH in Switzerland – whose firm has been using the OSSTMM methodology since its inception – recently commented on the value proposition the methodology standard offers, stating that, “the most important aspect is that we have an easier time keeping our clients. Most of the companies and organizations which order security audits on a regularly basis are fairly well organized and have a strong interest in gaining and keeping an adequate level of security.”

“Having the attack surface metrics, the ravs, means that they can watch trends and keep a close eye on how changes in operations affect their security directly. I can definitely confirm that many of our clients who have to change the supplier for security policy reasons expect their future suppliers to apply the OSSTMM.”

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

Social networking business models

A colleague who has a startup in the US for social networking for doctors was whining to me the other day that advertising business models are dead for everyone except the top 5-10 Internet properties like Yahoo and Google. He said that Google does a great job of aggregating ads from small Web site but that doesn’t mean that a small-mid size Web property can monetize traffic enough in order to be profitable. It’s a corollary of the long tail of the Internet, that the small guys a the end of the tail will never have enough traffic to monetize.

Continue reading

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

What do hackers want?

What do hackers really want?

No question is more important for mounting  effective security countermeasures. The management, IT and security practitioners cannot expect to mitigate risk effectively without knowing the objectives and cost of potential attacks on their organization.

We all depend on transaction processing to run our business and make decisions, no matter how big or small we are. We all use business applications (most of them Web-based these days) to buy, sell, pay vendors and collect from customers.

The prevailing security model predicates defense in depth of transaction systems. The most common strategies are to mitigate risk with network and application security products that are reactive countermeasures; blocking network ports and services, detecting known application exploits, or by blocking entry of malicious code to the network.

Are any of these security countermeasures likely to be effective in the long-term? Can attacks on a business be neutralized with defensive means only? In other words, is there a “fire and forget” security solution for the business? The answer is clearly no.

This is for three reasons:

  1. You must understand the attacker. If you understand what a terrorist wants (suicide bomber in a shopping mall sometime next week),  you can save lives with a preemptive attack. In the physical world – we defend the citizens of our country with both defensive and offensive means.  Often a political decision that is up for public scrutiny and criticism, nonetheless we do attack our enemies – with military action; commando raids, precision bombing or carpet bombing.
  2. You must understand yourself. Defensive “fire-and-forget” security countermeasures such as an IPS are not a replacement for understanding of where the threats lie and how much your assets are worth. A  Checkpoint SmartDefense firewall can help protect against malformed IMAP commands but  it cannot detect extrusion of proprietary company assets in a gmail attachment. An application firewall can help mitigate well-known XSS vulnerabilities but won’t fix bugs in customized application source code or mend system configuration problems.
  3. You must consider the alternate cost. There is no reason for us to attempt to take rational decisions in the real world but abstain from cost-benefit calculations in the cyberspace.  The cost of mounting a cyber attack on a company, bribing/social-engineering an employee to mail a file with all employee details is far less than what the company spends on its information security systems. With  inherently asymmetrical costs of cyber defenses versus cyber attacks, it’s high time to change the rules. Robert Bejtlich has a fascinating discussion on his blog – Mutually Assured DDOS. It’s a catchy title with a lot of interesting insights – but personally – I am not sure that projection of power and deterrence and mutually assured destruction is an acceptable corporate or government business objective.
Tell your friends and colleagues about us. Thanks!
Share this