Tag Archives: software design

What is the best project management software for a startup

Somehow I got roped into a thread on Quora and noticed this item http://www.quora.com/What-is-the-best-online-project-management-software-for-a-startup

Lots of people shilling their Web 2.0 SaaS services for project management but at the end of the day, you have to ask why a startup even needs project management software.

I’ve been thru a few startups either as founder or CTO and I’m surprised that no one has mentioned the easiest and cheapest project management system of all:

A pencil and paper.
The average startup in the software space is 3-5 people. Right? 3-5 people is a small army when it comes to developing software and who is going to be coding if they are busy using same fancy Web 2.0 app like Clarizen to manage Gantt charts and integrate with SF.com

Your first order of business is to iterate quickly and get real people using the product.

Hold on a minute – what about the design?

Yes, Roberta, there is no design.

If there is no design, then there is no Gantt and no 200 page SRDs, PRMs, SES, SRS, SIS, SDA and all the other vintage SDM-70 TLAs

Instead – you have an idea. A few smart people. A software architecture and set of programming standards that you can write down in less than 20 pages.

So – you have a startup.

You can spend the time coding and selling or you can spend the time planning, updating your Gantt charts and having ops reviews.

As a programmer colleague once said: “Code overrides all memos”

 

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

The Microsoft monoculture as a threat to national security

This is probably a topic for a much longer essay, but after two design reviews this week with medical device vendor clients on software security issues, I decided to put some thoughts in a blog post.

Almost 8 years ago, Dan Geer, Rebecca Bace,Peter Gutmann, Perry Metzger, Charles Pfleeger, John Quarterman and Bruce Schneier wrote a report titled: CyberInsecurity: The Cost of Monopoly How the Dominance of Microsoft’s Products Poses a Risk to Security.

The report from a stellar cast of information security experts and thought leaders shows that the complexity and dominance of Microsoft’s Windows operating system in US Federal agencies makes the US government prone to cyber attack – a national security threat.

This was in September 2003.

Now fast forward to a congressional hearing on May 25, 2011 by the Committee on Oversight and Government Reform on “Cybersecurity: Assessing the Immediate Threat to the United States Listen to the youtube video – you will note the concern on potential damage to citizens due to virus infecting government PCs breaching personal information.

So the US government is still running Microsoft Windows and is still vulnerable to data security breaches. It seems that the Microsoft lobbying machine has been “successful” over the past 8 years on the Beltway, if you call threats to national security a success.

One of the commonly used canards by Microsoft monoculture groupies is that all operating systems have vulnerabilities and Windows is no better nor worse than Linux or OS/X. If “you” patch properly everything will be hunky-dory. There are a number of reasons why this is fallacious,  to quote the report:

  • Microsoft is a near-monopoly controlling the overwhelming majority of systems. This means that the attack surface is big, on a US national  level.
  • Microsoft has a high level of user-level lock-in; there are strong disincentives to switching operating systems.
  • This inability of consumers to find alternatives to Microsoft products is exacerbated by tight integration between applications and operating systems, and that integration is a long-standing practice.
  • Microsoft’s operating systems are notable for their incredible complexity and complexity is the first enemy of security.
  • The near universal deployment of Microsoft operating systems is highly conducive to cascade failure; these cascades have already been shown to disable critical infrastructure.
  • After a threshold of complexity is exceeded, fixing one flaw will tend to create new flaws; Microsoft has crossed that threshold.
  • Even non-Microsoft systems can and do suffer when Microsoft systems are infected.
  • Security has become a strategic concern at Microsoft but security must not be permitted to become a tool of further monopolization.

As a  medical device security and compliance expert, I am deeply concerned about medical devices that use Windows. If Windows is a threat to national security because it’s used in Federal government offices, Windows is really a bad idea when used in medical devices in hospitals.

I’m concerned about the devices themselves (the FDA classifies Web applications as medical devices also if the indications are medical-related) and the information management systems: the customer support, data collection, analysis management applications that are ubiquitous to networked medical devices.

There are two reasons why the FDA should outlaw Windows in medical devices and their information management systems.

Reason number 1 to ban Windows from medical devices is complexity. We know that the first sin of the 7 deadly sins of software development is making the software complex.  Complexity is the enemy of security because with complex software, there are more design flaws, more software defects and more interfaces where vulnerabilities can arise.

Similar to the history of data security breaches of retail systems, the medical device software industry is (or may soon be) facing a steeply increasing curve of data security and patient safety events due to the Microsoft monoculture.  We are not in Kansas anymore – not credit cards being breached, but entire hospital networks infected by Microsoft Windows viruses and patient monitoring devices that stop working because they got blue screens of death.  Since 300 million credit cards have been breached, it is a reasonable assumption that your card and mine is out there. The damage to your credit card being breached is minimal.  But, if your child was on a patient monitor that went offline due to a Microsoft Windows virus and a critical condition was not detected in time; it’s the difference between life and death.

The complexity and vulnerabilities of Windows technologies are simply not appropriate in the medical device space when you look at the complexity and weight of the components, the SQL injection vulnerabilities provided courtesy of naive ASP.NET programmers and the ever present threat of Windows viruses and malware propagated  by USB sticks and technician notebooks.

The Microsoft monoculture breeds a generation of programmers that are scared of the command line, unable to comprehend what happens behind the GUI and lured by the visual beauty of the development tools.  When a programmer uses a component and doesn’t know it works (see Visual Studio ) and shleps around a shitload of piping in his project, then the energies go into implementing a cute GUI instead of thinking about code threats.

This is on a grander scale, a rerun of Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Reason number 2 to ban Microsoft Windows from medical devices is more subtle and related to systems management.   The Microsoft monoculture has bred a particular kind of thinking and system management best practices based on Windows servers and Windows PCs running in the office.  This IT system management strategy assumes that PCs are just personal devices that someone has to patch and that they will eventually get infected and or breached and or get a BSOD.

Unlike an office, a hospital is a highly heterogeneous and hostile environment. The system management strategy for network medical devices must be different.

Medical device vendors need to assess their software security with the design objective being a device that runs forever and serves the mission of the doctors and patients.

Medical devices are real time embedded systems living on a hospital network. They should be fail safe, not vulnerable to viruses and should not have to rebooted every few days.

Yes – it’s a tall bill and a lot of people will have to learn how to write code in embedded Linux.

But, there is no alternative, if we want to prevent the medical device industry from suffering the ignominy of the credit card industry.

 

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

Medical device security in a hospital network

Medical devices are everywhere today.  In your doctors office measuring your blood pressure, at your cosmetician (for hip reduction…) and in the hospital for everything from patient monitoring to robot-assisted surgery.

The people that develop embedded medical devices based on Intel platforms know that Windows is vulnerable.

Lacking embedded Linux know-how, medical device developers often end up adopting Windows and Visual Studio as a default. Using Windows is a security-blanket for developers who grew up in the Microsoft Windows monoculture and are scared of the Linux command line.

But – make no mistake using Windows in networked embedded medical devices is a mistake.
This is big mistake #1.

The top 2 threats to a medical device are software defects and software updates.
Consider the implications of updating patient monitoring devices in a hospital with an infected USB stick or an infected Windows notebook.

In product development (and medical device are  no exception),  the support and version update process  is often something  left for the end of the project. At that point, when the product manager asks how are we going to update the software in the field – the hands raise in favor of  USB memory stick updates as an “interim” solution.

It is crucial to use threat analysis on systems of networked medical devices in order to arrive at the right, cost-effective countermeasures (apropos the management challenge of large number of VLANS…). Threat analysis must be an integral part of the SDLC (software development life cycle) – done early in the process and validated from time to time whenever there are significant design, configuration or environmental changes.

Threat analysis enables a medical device vendor and the hospital security team to have an objective discussion on balancing the need to protect the hospital network asset with protecting the availability of the medical device  itself and concomitantly – the safety of patients that are dependent on the device – patient monitoring is the first example that comes to mind.

Unfortunately many device vendors and their hospital customers use a system management model based on Microsoft Windows and business IT management practices. This is big mistake #2.

Medical device vendors need to assess their software security and not assume that an embedded medical device running Windows XP   is no different from any other Windows PC on the network running Office 2007.

To use an analogy from the world of real time embedded systems – consider avionics as key to safety of the pilot and success of the mission. Avionics are not managed like a network of Windows PCs and neither should medical devices on the hospital network.

A medical device in a hospital network – whether it monitors patients, assists in surgery or analyzes EEGs – is an embedded device in a extremely heterogeneous and hostile environment that should simply not be vulnerable to Microsoft Windows malware.

Embedded medical devices should be based in embedded Linux – and not a stock version of Red Hat – but rather built ground up from the latest Linux kernel, with the minimum set of services and software (Qtk etc…) needed to run the application.  The software update process should be part of the design – not something bolted on after the implementation.

Developing for embedded Linux is not copy and paste from Windows. It requires expertise to setup the basic infrastructure.  But – once that infrastructure is up, the medical device developer and it’s hospital customer can be confident that they are standing on a secure platform and not a house of glass built on a foundation of sand.

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

Customer security with software security

If you are an IT person, this article may be a waste of your time. But – if you are in the business of making and delivering products with software inside – read on.

What threats really count for your business?
No question is more important for implementing an effective security and compliance program for your product development. The management, the software developers and security analysts cannot expect to mitigate risk effectively without knowing the sources and cost of threats to company products and the products’ users.

The prevailing IT security model predicates defense in depth of IT systems. The most common strategies are to mitigate external threats 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 for software applications and software-based appliances? Can attacks on a software product be neutralized with defensive means only? In other words, is there a “black-box” security solution for your products?

The answer is clearly no.

A reactive network defense tool such as a firewall cannot protect exploitation of software defects and an application firewall is no replacement for in-depth understanding of company-specific source code or product configuration vulnerabilities.
This paper presents a rigorous software development process for delivering secure software product starting with a simple notion – “buggy software is insecure software”.

By removing software defects we are in the best position to deliver secure software to our customers.

Download the full article Make your business secure by making your software secure

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

Designing a data security system

User-Driven Design versus User-Centered design

Alan Cooper, in his book The Inmates are Running the Asylum, draws a distinction between user-centered design and user-driven design. User-driven design is about collecting, prioritizing and implementing a system to the user requirements – we’ve all been seen software development projects where the requirements spiraled out of control and the project was a painful flop. On a project like that – it’s best to detect the warning signs early on and bail out in order to save your sanity and reputation.

User-centered design, on the other hand, is about listening carefully to the user and implementing friendly, reliable, fast and secure software that meets the user business requirements.

There is a lesson to be learned here for data security and data loss prevention –

Continue reading

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