Large enterprises rely on software products. And as everything else in large enterprises, the software products are large, complex, cumbersome and nearly unchangeable. This last attribute is better known as vendor lock-in. Software vendors love vendor lock-in. Here is a definition borrowed from Wikipedia:

Vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs

The problem
Vendor lock-in exists in most large enterprise industries like Telco, Healthcare, Finance, Energy. Such industries rely heavily on certain computer systems or software products, usually dubbed Core Systems. Because most of the business transactions, logic and information are stored and processed by these Core Systems, the transition to a different Core System vendor is extremely costly and time consuming.

So most large enterprise companies simply continue to operate with the same Core System vendor, while they suffer:

1. delays in patch or version delivery
   
2. poor quality product versions
3. inadequate compliance from the Core System to their local law and regulation
4. ever increasing maintenance costs.

On the other hand, switching to another Core System vendor will result in probably the same end effect, with the added costs of the switchover.

The solution
So is there a way to improve your position? Indeed there is, but with a radical move: there is only one thing that any software vendor reacts to - risk of decrease in earnings from a customer.
To make this risk a reality for the vendor, the customer needs to reach a situation where competitors can successfully bid for software upgrades and new functionality without actually switching the Core System.

This is most easily achieved through the Core System's API interface. Most Core Systems have extensive Application Programming Interfaces (API), which can be used to exchange data with the Core System or issue commands to it.


So instead of asking for every possible modification or new functionality from the Core System vendor, just use it as a processing core - move everything else to other developers, which will need to adhere to the Core System API specification.

This way you can outsource the development of a lot of applications to other vendors, achieve better response from everyone and always have healthy competition. Oh, and it will keep the Core System vendor on it's toes!


Talkback and comments are most welcome

Related posts
Software vendor relationship - can you make it better?
3 rules to keep attention to detail in Software Development
Security challenges in software development
Paying for Software Support - When to do it?

Your company bought a corporate software solution. Your teams tweaked, modified and tested to get it up to your requirements. Now, you just continue to use it for the next 20-30 years without problems. Right?

Well, not quite. The marriage between a corporation and a software vendor has a tendency of turning ugly as time passes and here is why:

• Software Vendor Greed - You are tied up into maintenance and upgrade contract, with a yearly fee. And lately, the largest software vendors are increasing these fees as new sales are dropping. The latest example are SAP and Oracle, and they are actually blaming it on Inflation - Here is a great article on this tendency http://blogs.zdnet.com/BTL/?p=9717
• Customer treatment - After a corporation has migrated it's core data into the new software, and sufficient delta time has passed to make the reverse migration into the old system impossible (usually 3-6 months), the software vendor relaxes. He know that the customer is his for the foreseeable future, since migration back or to another system is way too costly, in time, money and human effort. So the software vendors becomes less responsive, focuses on new deals, and in extreme cases even becomes outright arrogant
• Software Quality Failures - What initially seemed like a minor issue, can grow into a big ugly monster of a bug as the dataset grows, or as errors creep into the system. And the software vendor may choose not to address the core problem, simply because it is too costly or not really possible to be fixed without a full overhaul. So what usually happens is that your company ends up throwing ever more powerful hardware at the problem in the hope that raw speed will help alleviate the issues.

So, is there a way to kick the software vendor where it hurts and make them work as good as the first time they sold a solution?

There is no silver bullet solution, but the following suggestions can help a lot:

• Put a big stick in the purchase contract - Include software issues resolution time and change request reply times bound with severe penalties in the original purchase contract. This way, all you need is to enforce this SLA every time the software vendor slips. Pretty soon the software vendor will have to bite the bullet and start dedicating it's resources to you - simply because it will cost them way too much to treat you bad.
• Put a carrot in front of the software vendor - Place a condition of payment for any new expansion or module purchase with clearance of all outstanding issues in the original software.
• Always plan a contingency - Have a planned alternative solution. This is the most difficult solution - and the most costly to complete. But when in dire straits look at alternative solutions - especially fully managed (outsourced) alternatives. With these alternatives your organization is the user of a software, and most of the effort of migration in terms of hardware and resources is offloaded to the outsourcing company. Oh, and by the way, once the software vendor understands you have an alternative, quality will definitely improve.

Talkback and comments are most welcome

Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software development

Security challenges in software development

Testing of any solution, especially software is a very slow and painful process, which requires a lot of human resources and proper design of test scenarios. Because of the slowness of the process, something can be missed.

So a number of companies organize competitions in which they offer rewards to whomever breaches the security, finds a bug or similar activity to their software. Jon Oltsik in a text titled Carnival atmosphere in security compares this process to carnival and criticizes it heavily.

Although I agree that the competition is not a good approach, here is a more constructive analysis of the reasons:

Benefits
Here are the perceived benefits of a competition style testing of any software. All of them are naturally legitimate, and every company would like an army of very dedicated testers for their product, at a price at which they'll never be able to hire so many testers:

• The application will get stress tested - An army of testers hunting the prize will put the software through it's paces and make very creative use cases to reveal bugs.
• A lot of boundary conditions will be checked and re-checked - These bug-hunting testers will throw all kinds of garbage at the software, precisely where most applications fail and open a way to fraud, security breaches or simply erroneous operation.
• Implementations of standard protocols and algorithms will be checked for errors - the most frequent path to breach of application or system security is the poor implementation of the standards that are trusted the most. For instance, while AES encryption is virtually unbreakable within an acceptable time frame, it's poor implementation in program code can lead to easy exploits and breaches. Such errors can be identified in a prize hunting test.
  

Drawbacks
Naturally, it's not all good. There are several risks to using a competition for software testing, and here are the most very dangerous pitfalls:

• Only one winner - Only one vulnerability. This method of testing will actually identify only one vulnerability. There can be several controls to prevent this situation, like a submission time after which a winner is declared, but usually the first hacker to perform the breach will use covert channels to advertise his success, to deter other competition and to increase his reputation.
• Bugs publicized in the wild - A lot of other bugs and potential errors can be identified during the test, but these will not create the effect to win the prize. After the competition, information about these bugs can suddenly become available "in the wild" and the software company will not be aware of them. So a lot of people will get their hands on a list of bugs and can attempt some attack with them.
  
• A lot of potentially malicious groups can become very familiar with the software- In order for the competition to have any effect, the software needs to be distributed to everyone and their mother, no questions asked. This means that a lot of teams will learn the inner workings and the processes of operation of the application. In a standard test and delivery process such a corporate scale application, the general public does not know how to use it. While this security by obscurity is not too effective, it is another deterrent against attempts at fraud or attack.

Conclusions
There are visible benefits and a lot of good PR for anyone organizing a competition testing of it's solution. However, in the long run, the majority of valuable results of the tests will not be returned to the organizer of the competition, so there will be little benefit when the prize money is spent to close only one vulnerability.

So, unless you are up for a publicity stunt, when organizing a test, approach the process as a reward based test, but under controlled conditions (your testing facilities, scenarios to be filled and submitted for each bug found, etc.) and then reward the testers for each found bug.

Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software development

Security challenges in software development

Talkback and comments

A software development company can be impacted when trying to modernize their development tools or environment - improper verification can lead to incompatibility with the code, a lot of lost time and energy and a whole lot of headaches for the teams and managers. Here is an analysis and mitigation recommendations how to avoid such a situation:

Example scenario:
Democorp is producing an ERP application written in Java, and running under the Tomcat application server.
The head of ERP development read about the improvements in the new Tomcat version 6, and instructed his core team to adopt this version for further development. Even though there were complaints from the team, everyone started the shift.

It takes 2 days to shift from version. 5.01 to 6, since the Tomcat's structure has changed. In the end, one of the lead programmers attempted to compile the application 3 times, simulating a boundary scenario of Democorp's customers.
The application run out of memory on a 8GB server. After 1.5 days of attempts by the core team, one of the programmers finds an entry in the forums that Tomcat 6 causes a memory leak in a library that Democorp uses in their ERP application.
After this, one member of the team is tasked with testing and correcting the problem, while the others are reverting back to Tomcat 5.01, which takes another 2 days.

Analysis
Due to an unconfirmed idea by the head of development, the core team of 7 people lost 6 days - 42 man-days on attempting to migrate development platform to a new version.
At the end of the day, one person was dedicated to testing before further rollout - a solution that should have been used from the start.

Conclusions and Recommendations
This was a poor management move of the head of development - with all the new features available, his priority still should have been maximal efficiency of the team.
To avoid these situations and achieve maximum productivity during change in tools or technology, you should observe the following rules:

• Treat the development tools as trusted - These are the tools you use to produce production grade code. Never change tools or environment in development simply because it's nice - test everything
• Perform risk analysis - Consult all other teams and perform a risk analysis of all possible impacts of the change. There can always be something you overlook that impacts the other teams.
• Make a phased introduction - even after everything is tested, don't make a big bang change. Have one or a small number of people within each team adopt the change and work with it, to weed out possible overlooked problems

Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software development

Security challenges in software development

Talckback and comments are most welcome

All large businesses rely on software solutions to manage many aspects of their business. In time, the business grows so accustomed to the "system" that they deem it authoritative for all information and rarely question it's outputs. When this point of trust is reached, any error in that system can go unnoticed and have a tremendous impact on the organization, even put it out of business.

Example scenario:
A Billing system, Provisioning system and a General Ledger is the core system of an electrical supply company IT support systems. The billing system calculates the bills according to usage data records, the provisioning system activates and deactivates customers and the payments of bills are processed through the General Ledger System system, and are matched to the information in the billing system.
Due to marketing strategy, the company defines a change in billing model for one of their products, to include the ability of no subscription charges under certain conditions. The manufacturer of the billing system dispatches consultants to configure the new product into the billing system.
The consultants configure the new product, and reconfigure the billing parameters for the product. The product is tested successfully for proper billing and rolled out. It is a commercial success, and significant number of customers are using the new product.

A month later, the Board of Directors requests a report on the number of customers who haven't paid their bills . The Provisioning system is generating these reports from specific markers in the customers account within the billing system. The generated report indicates large number of customers of the modified product have not paid their bills.
Based on this information, the Board publishes an advertisement warning all non-paying customers that they will be disconnected. After 2 weeks, the report still shows no change in number of paid bills, so it is decided to disconnect these users for a warning period of 2 hours.

The following morning the disconnection is executed. By the end of the day, at least 400 customers have filed lawsuits against the company for breach of contract, since they have paid their bills.

Analysis:
The ensuing internal investigation identified the following problems:

• When modifying the product, the consultants actually created a second version of the product which didn't have subscription charges.
• This new product was integrated into the GL system for payment processing, but due to oversight, the process didn't mark the bill as paid in the billing system.
• Nobody bothered to check whether this marker is being updated, assuming that everything is automatic.
• The provisioning system looked at the erroneous markers showing unpaid bills, but nobody doubted the produced report, nor made any effort to make manual or different automatic verification.

Conclusions and Recommendations:
As stated in the introduction, the real cause of this incident is the unquestionable trust in the system. In a broader aspect, the following mistakes occurred:

• Poor implementation by the consultants - they implemented a change and didn't properly communicate the performed change
• Poor testing and verification by the utility company - the testing scenarios did not include all relevant aspects, like the paid bill marker for provisioning
• Blindly trusting an obviously unnatural report by both operational teams as well as the board - nobody who had access to the report actually identified a problem with it, although it is very hard to comprehend that SUDDENLY NOBODY PAYS his bills.

To mitigate risks of errors in a system, an organization should implement the following controls:

1. When implementing system changes, obtain verification and advice from all interested parties - in integrated systems, everyone uses data from everyone else. So technology architects or system custodians should confirm that the change affects their system in a expected manner.
2. When testing system changes, include standard tests from all interested parties - like the previous point, everyone should fire a battery of tests from their own point of view. This is the best way to identify integration risks
3. For all critical and business impacting reports and functions, implement an automatic comparison control that observes the information from a different aspect - for the example above, another report from GL listing the number of payments to the utility company could have been compared to the report produced by Provisioning. An immediate discrepancy would have been identified
4. Institute regular operational on-site controls with verification of a sample set of system information to paperwork - where automatic systems aren't available, perform regular manual verification with a sample set of data

Related posts

3 Controls to Secure Corporate Offline Computers

Control Delegated Responsibility

8 Tips for Securing from the Security experts

Talkback and comments are most welcome

The easiest way to create a bad product in custom development is to misunderstand the customers expectations. This is a discussion of risks that are brought by poor specification, poor understanding of business needs and the hurry to make a profit.

Medium size businesses are usually partnering with one or two software development companies. These businesses are entering a partnering relationship with the software company, and nearly always turn to them for their solution needs.

From a business perspective, this arrangement makes sense for both sides.

1. The business has the guarantee that whatever new product is delivered will be able to seamlessly integrate with their current systems.
2. The software development company has a broadened influence on the business and knows that they will extend their cooperation for at least several years more.

The problem with this arrangement is that the customer is trusting the software supplier to deliver any and all possible solutions, even those that aren't in the core product line of a software development company.

Example scenario
Shortinfosec Democorp is using a Customer Relationship Management (CRM) system developet by ACME Software Devel. According to the new business model of Democorp, a new billing system is needed for proper invoicing of delivered goods and services. ACME Software Devel is invited to create the billing system. The requirements given from Shortinfosec Democorp are the following:

• The system needs to generate invoice for all customers summing up all their outstanding charges
• The system needs to be able to create discounts for VIP customers in the CRM system
• The system needs to produce reports for invoiced and outstanding amounts

ACME Software Devel receives the specification, confirms ability to finish the job and creates a product. During testing of the delivered product, the following issues are raised by Shortinfosec Democorp:

• The billing system does not interface with accounting, to track payments
• The billing system does not calculate interest on late payments
• The billing system operates with the current product set, and there is no flexible way to implement new products
• The discounts are limited to fixed amount or fixed percentage for the VIP customers
• The reporting aspect is limited to 2 reports

ACME Software Devel responds that these issues were not mentioned in the initial specification, and requests a 3 times increase in agreed price to deliver the required changes. After tense negotiations, ACME Software Devel is contracted to scrap their solution and provide interfaces for a third party billing system. Shortinfosec Democorp hires a consultant to define all requirements and issues an international RFP for the Billing System.

Analysis
The process described above was riddled with errors.

1. The original specification given by Shortinfosec Democorp is quite poor and abstract - The project manager for the billing system did not do sufficient research to identify all the required aspects of the desired solution
2. ACME Software Devel. assumed that the specification is final and that the product is very simple - The software company account manager and project managed did not expand the analysis with the customer to investigate all possible issues.
3. Based on assumptions that the other side knows it all and will tell/do all that is needed both time and money were spent. - The process was at least doubled in costs and time frame.
4. The entire exercise ended in tense relationship and diminished trust between both partners - Both parties were left dissatisfied by the other one, and a good business relationship was degraded.

Recommendations
While it can always be discussed that the responsibility for functional specifications falls on the buyer, the software development company should seize the opportunity to help or guide the buyer to produce a mutually agreed good product.
Here are several steps that should be taken to improve the cooperation between partners in creating a new software solution.

1. Never assume that the specification is all the customer needs. If the specifications are too inconclusive or general, strive to specify them in greater detail. This will reduce the need for assumptions and possible incompatible design in the finished product.
2. Research the market, see what is actually behind the simple sentence uttered by the buyer. For instance, the buyer might like the idea of a software managing the queues of people in front of their sales counters. But this software is known as customer flow management, and is an entire science of it's own.
3. Establish a good and permanent collaboration with the buyer. Collaborate as much as possible in the early stages - even when the new requirement is still an idea. Always present
4. If necessary (often it is, to reduce conflict of interest) suggest an external consultancy to assist the the buyer in the process of defining requirements, so that the finished specification is easy to follow.

Related posts

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software developmentSecurity challenges in software development

Talkback and comments are most welcome

Branching of software versions is a regular and everyday process in software development. However, branching brings inherent information risks that require good controls and regular oversight. Here is an analysis of these risks and the possible controls to mitigate them.

Example scenario:
Shortinfosec Democorp has sold a software package to a customer company. The software package is rolled out in February and running well.
In June, the customer company is requesting a very specific upgrade.
Due to lack of resources, Democorp is scheduling the upgrade for the next planned version, which will happen at the end of the 12 month cycle (next February).
The customer company needs the upgrade asap, so it is agreed that the customer will create a patch for the software which will provide the required functionality. The patch is applied in July and running well.

During October Democorp software maintenance has prepared a patch that improves the performance of the overall solution. This patch is distributed to the customer and is applied to the system.
The next morning, the customer's data is corrupted, and needs to be restored from backup.

Analysis:
Incident management identifies that the customer created patch has failed and corrupted the data.
In depth analysis concludes that the performance patch has changed the underlying architecture of the software package, which caused the functional patch created by the customer company to fail.

This is a very common risk when failing to manage the possible branches of the software product and can sometimes lead to dire consequences.

Controls:
When preparing custom solution applications, it is quite common that the application management of the customer are allowed to create certain supporting elements around the core solution. In extreme situations, like the example, they may even intervene within the core solution with a temporary workaround.
All these in-house developed solutions are based on the documented technology and architecture of the core solution.
Here are several methods that can be used and combined, in order to mitigate the risks associated with the developed branches.

1. Establish standard and documented API's so the customer can interface with the core solution without the nececity to intervene directly into it. Maintain the API's for backward compatibility, and announce compatibility impacting changes to the API's at least 1 year in advance.
2. Establish a practice to inform the customer of any technology changes in each new version and patch.
3. Establish a cooperation protocol between the manufacturer and customer by which all in-house developed code supported by a core solution should be acknowledged and confirmed by the software manufacturer. By this protocol, the in-house code can be then maintained by the software manufacturer, or the software manufacturer will have to specifically alert the customer of changes impacting the in-house developed code.

Written by guest blogger - Marija Spirovska, currently holding position of senior developer at a multinational software company.
ShortInfosec thanks for her contribution, and hopes that she will continue to contribute to this site.

Related posts
3 rules to keep attention to detail in Software Development
8 Golden Rules of Change Management
Application security - too much function brings problems
Security risks and measures in software development
Security challenges in software development

Talkback and comments are most welcome

All corporate data within a company should be subject to the CIA triad: Confidentiality, Integrity and Availability. One of the elements that can become a risk to data integrity is an incorrect version of software.

Example scenario:
The IT department rolls out a new version of the CRM application at Shortinfosec Democorp.
Due to specific requirements of the director of sales, his assistant's computer does not update the CRM application automatically. At the moment of the rollout, her computer was off, and was unreachable for a manual update.

The following morning, the director of sales gets a call from a VIP customer with a new order for a high-end network analyzer. He calls up his assistant and instructs her to insert new order into the CRM. The assistant uses her CRM program and inserts the new order.
As a result, the order multiplies to all VIP customers, which triggers a lot of confusion in account and order management until it is resolved.

Analysis
During the rollout of the new version of the CRM program, the CRM database was updated to function with the new version of the front end. This included a modification in the engine that manages orders, and resulted in erroneous.

Recommendations
Incoherent versions of frontend and backend can create any number of problems with the underlying data, corrupt it or even destroy it. The following measures should be implemented to mitigate the risk to data integrity from wrong versions:

1. The software manufacturer should implement a function within the application which will compare the application version to an expected current version stored in the database.
2. The expected current version should be updated within the application database during the rollout, using a standardised and documented process delivered by the software manufacturer.
3. If the application version does not match the expected current version, it should either visually and audibly alert the user of the incoherence, or refuse to function.
   
4. The company that purchases the application must implement a policy by which employees will immediately alert IT when they see a message of wrong version.

Related posts
3 rules to keep attention to detail in Software Development
8 Golden Rules of Change Management
Application security - too much function brings problems


Talkback and comments are most welcome

A standard practice in software companies is to put the new hires, often not properly trained to productive work as soon as possible. This practice is an understandable business requirement, but if not controlled properly can lead to bug creep or unwanted complexity in the code.

In my experience as a software developer, i can name hundreds of situations where poor code caused days of debugging or corrections.

Here is one, very simple example:

When creating an array of data in Java, one uses a constant for the array dimension. When using the created array for sorting, or searching through the content of the array, one creates a FOR cycle, starting with 0 and ending with the constant number size of the array.
What will happen when a user requirement demands the extension of the same array? A programmer (usually one that has wronged the project manager) gets assigned to changing all values of the array size in the entire code. This will probably be a couple of days very very of tedious work.
If the initial code used the length method of the array in each FOR cycle instead of the constant size value, the entire change will be only to the constant used to create the array. Suddenly, this becomes a 5 minute job (which you can still charge 2 man days to the customer).

To sum up, here are the 3 rules of keeping attention to detail and good programming practices in your companies

1. All software companies have a document named 'Development Standard' or 'Development Conventions' or the like. This is the new hires' bible of work, and everyone should check that the new hires know and understand it before putting them to work on a commercial piece of code.
2. The Development Standard document should not be written once and forgotten. Mandate a regular standard review and upgrade by your best and most experienced developers, at least once a year.
3. For good measure, amend your Development Standard with the latest edition of a good book on your programming language of choice. Things get forgotten, and this will provide a fast refresher course material for your developers.

NOTE: This post was written by a guest blogger - Marija Spirovska, currently holding position of senior developer at a multinational software company.
ShortInfosec thanks for her contribution, and hopes that she will continue to contribute to this site.


Related posts

8 Golden Rules of Change Management
Application security - too much function brings problems
Security risks and measures in software development
Security challenges in software development

Talkback and comments are most welcome

Regardless of the size and complexity of infrastructure you are running, it is always very important to have an established process of change management to your resources. If you fail to establish or enforce such process, errors will inevitably start to creep but will largely go on unnoticed, until something bad happens.

The example
A small company I visited yesterday is running several high profile paid content web portals. While discussing a research i did for them, the CTO changed the subject: I need a fast way to know when my staff made changes to my servers. I must admit that this question caught me by surprise, since I had no insight into their operations. After 15 minutes of conversation on the topic, i concluded that they don't have a process that controls which changes to the infrastructure are made when and under whose authority. This led to a situation where one developer implemented a new version of the software, while another made changes to access permissions. The result - a hacker made copies of their content and published it on IRC channels, resulting in direct monetary loss.

This is an excellent example that there is no company small enough to justify not having a strict change management process.

The rules

Here are the golden rules of establishing a change management process

1. Make a clear distinction between systems
   Production environment is the place where you run your business. Nothing except approved versions of approved software should be running there.
   Test environment is the place where you check your next versions. In configuration and set-up it should be as close to production as possible.
   Development environment is the place where you develop new products. It is to be expected to be riddled with all kinds of code, and some testing will be done on it, but don't confuse it with a test environment
2. Know exactly what is running in production - Establish a documented process of applying changes and versions to production. Make regular checks that this process is being used in daily operations
3. Develop changes based on current production environment - Unless implementing a entirely new solution, maintain a protocol by which all further development takes into account the setting and versions on production. This way, your next version will always start from a tested core code, where you know or have weeded out most of the bugs
4. Always run a full battery of test scenarios - When testing new versions, write test scenarios, and test the full software, not just the new features. It is very common for working functions to be broken by a seemingly unrelated change.
5. Never institute several changes simultaneously - If something goes wrong, no one will know what change is problematic, and everyone will blame everyone else. When making several changes make them one by one. Between each change, reserve as much time as possible to confirm that all is working before making the next change.
6. Always have a fallback plan when placing a new version in production environment - It is not WILL something go wrong, it is WHEN will something go wrong. The implementation team should have a written fallback plan when applying changes to production. This plan should include a responsibility for a human to oversee production operation at least in the first 12 hours after the change is made, to be able to react on first sign of trouble.
7. Assign responsibility to a person - Group responsibility doesn't work. Name one person Change Manager or Coordinator. It will be his responsibility to oversee testing results and changes on a daily basis and coordinate multiple changes.
8. Always insist on regular reporting - The CIO/CTO should receive regular monthly one page report on what changes were moved to production, test conclusions and next planned versions. Although not immediately useful to the manager, the responsibility for regular reporting will help to keep the process alive and used by the organization

Related posts

Security challenges in software development

Application security - too much function brings problems

Talkback and comments are most welcome

In the past 5 days i came across 3 examples which proved that too much functional complexity can backfire in terms of business competitiveness and security:

• The car example - I read an AutoBild 100,000 km test of the BMW series 7. Their biggest complaint was the iDrive system (no relation to Apple). The idea of BMW was that a single computer interface will replace the arrays of buttons and dials on the central console of the dashboard (from radio to suspension setting). The initial version of the iDrive system was so complex that it became a nightmare for the driver to use it. The end result-a very expensive car that is a difficult to use, and sometimes even dangerous since the driver is focusing on the iDrive instead of the road
• The phone example - My 2.5 year son loves to play with my cell phones. While usually interested in fiddling a phone for around 2-3 days before he got bored, he is still constantly playing with the iPhone. What is even more fascinating, he is quite adept to actually activating and deactivating the iPhone's features without any help from an adult except for the initial showing. Although not an actual user of the iPhone, he knows how to use most of its features.
• The software example - I was doing a review of an application design for a Engineering ACME company. This application has a feature which enables the user and manager to follow what actions are performed, and to revoke any of his commands even out of sequence, provided they are not interdependent. While a possibly good idea in the long run, the implementers placed the invocation of this feature the action history in many places, including one wrong place. With this wrong place, they caused a situation in which action history can be invoked even if the user is logged off, and a command for cancellation or re execution can be issued. While no harm can be done at the moment since there are no credentials to complete this change, the implemented mechanism of the action history cached the issued command and completed it upon a successful log-on of the user whose action is to be changed.

These three examples lead to the following conclusions:

1. It is rarely good to choose a solution only based on the function set it offers.
2. Bad implementation of functionalities can make a very expensive high quality product to a situation where people will be afraid to use it
3. Bad implementation or too much functionalities can make a product under perform, or cause a situation where people will be afraid to use it, thus not using the features they paid for
4. Bad or too fast implementation of functionalities WILL produce security issues which can even pass undetected into production
5. Good implementation will enable fast adoption of any product, no matter how inexperienced a user is
6. Simplicity of the user interface does not mean it is based on simple or inflexible engine.
   

The users, especially corporate users buy on number of functionality, not on the quality of implementation. But a complex poor implementation WILL backfire.

It is only a matter of time before it does. The later it does, the more problems the software developer will have to fix the problems, if he can fix the problems at all!

The iPhone and the iPhone community is an excellent tutorial for system architects and software engineers: Have a strong core, and develop functions one at a time. Don't just overload the system with functionality.


Related posts
Security risks and measures in software development
Security challenges in software development

Talk back and comments are most welcome

Following up on my post about security challenges in software development , i would like to present the risks that arise from these challenges, as well as short introduction on the preventive measures to mitigate such risks.

Product related risks

1. Security flaws of the deliverable product – the most feared of risks and usually one with most dire consequences. The product THE principal source of reputation and income for the company. At the same time, the product is the tool that a customer uses to manage his information and data. A security flaw in the delivered product can result in loss of integrity, confidentiality or availability of customer’s information. Any one of these results would mean loss of client, loss of reputation and even legal action against the development company.
2. Security flaws of the maintenance and support methodology – This risk takes on two forms
   a) INSIDER FACTOR – a security breach at customer's premises by an employee of the software development company involved in the maintenance process.
   b) OUTSIDER FACTOR – a security breach by an outside attacker who gained access to the customer’s premises by compromising the network infrastructure of the software development company
   It is quite clear that in this risk, the insider factor carries most of the risk weight. It should be duly noted that in this risk, the responsibility is mostly shared with the customer, since the customer should also implement security measures to mitigate and hamper such a risk.
3. Security flaws of the delivery method – the third level of risk in the product. Given that all is perfect with the actual developed product, improper delivery can expose the product to possible tampering by “man in the middle”. This tampering, even if later proven to have happened outside of the development company, would not clear the development company of all wrongdoing, since the creator of the product didn't perform analyze the aspects of risk in transit.

Operations related risks

1. Security Flaw in technical infrastructure – a risk which can cause great amount of problems, but which is easiest to identify, albeit sometimes expensive to remedy. A security flaw in the infrastructure can result in:
   a) Access, theft or intentional corruption/destruction of business critical data or information by employees
   b) Accidental loss or corruption of business critical data or information
   c) Outside hacker attack
2. Security flaws in operations practices – a risk which is can cause the same results as the previous point, but is much more difficult to identify, but usually much cheaper to remedy, since it requires change in procedure, not capital expenditures

Information security corrective measures

To mitigate the risks presented in this post, the following overall measures should be developed and implemented. The description of these measures merits the attention of a dedicated post, and they will be treated accordingly. Insofar, here is a brief summary

1. Top management must accept the philosophy of information security and actively sponsor, support and promote security. Also, they must be the first to fully adhere to all defined security procedures and rules.
2. The software development company should define precise guidelines for security in operation, development and maintenance, supported by top management:
   a) Security in the product must be set-up and implemented from the initial design and architecture. If this isn’t the case, security flaws will be abundant, and security patching will become a never ending firefight
   b) The infrastructure and privilege levels within the company need to reflect security policy
   c) All security incidents must be tracked from start to end, documented and communicated to appropriate levels within the company.
3. The employees must be regularly reminded that information security is one of the basic missions of the company; A regular security awareness and training program must be instituted for all employees, starting with employment and ending with the exit interview

Related posts

Security challenges in software development

Personal Data Protection - Anonymizing John Doe

Talk back and comments are most welcome

With the time i spent at Medic ACME gave me an insight into the workings of a rising software development company. All the items i am presenting here are already presented to the Medic ACME management, as Pro Bono work on my other engagement.
So, with their consent, i would like to present my conculsions. In the rush to achieve a good brand and reach the heights of profitability, any typical software development company has the following characteristics:

Get things done mentality – “This will be the largest contract in the history of our company. We must be prepared to deliver in 2 weeks/2 months. So get it working ASAP. A variant of this monologue is very frequent in most software development companies. Anyone telling you different is either lying, or not working as a developer for a living.
Tremendous workforce capacity – Regardless of race, gender or religion, the average developer/engineer is highly intelligent, technologically savvy, usually very up-to date with technical advances, and due to the high pace of technology, a person willing and able to learn new things in very short periods of time.
Frequently mixed duties – since the workforce has excellent capacity, it is quite often that the developers/engineers are given additional duties other then development.
Significant technical resources at hand – The developer/engineer has ready access to significant computing power and software tools, both in the form of a local workstation and server infrastructure.
Onsite delivery – Of course, while the product is still in the proverbial shop, and sales cannot invoice something that is not delivered. The delivery can take on several insecure forms

• The product can be sent via E-mail - not encrypted and digitally signed
  
• The product can be published on a Web portal or FTP server, again, not encrypted and digitally signed
• The product can be burned on a CD and sent via some form of courier service without protection from possible stealing or tampering
  

Maintenance and support in various forms – The second and/or third level of support for a software product falls on the shoulders of personnel from the development company. This gives access to:

• Error logs or crash dumps from the product which failed at the customer’s site, which usually contain a wealth of highly confidential information (usernames, passwords, confidential records etc)
  
• Depending on support contract access to the customer’s test or production servers remotely, opening the possibility to be suspected of information theft or tampering
  

Inherently, the organization of a software development company presents the following security challenges

1. The pressure to create a functional product with short deadlines can lead to development decisions which may prove extremely insecure in everyday usage of the product
2. The pressure to solve issues in maintenance and support can lead to untracked and undocumented direct modifications of software or database schema at customer premises.
3. The created product will be used at client’s premises – a security problem with the product can have dire implications on the customer’s business, as well as on the reputation of the software development company
4. Although rarely absolutely necessary, an overwhelming majority of developers have full administrator/root privileges on their local computer and sometimes even on their coworkers computers
5. Although never necessary, and always very dangerous, a vast majority of developers share the administrator/root account of development servers, databases and sometimes even network elements like routers and firewalls
6. To reduce costs and optimize hardware utilization, the internal operations databases, business support systems, internal confidential file stores and the like are often supported and maintained on the same systems that house the development environments or databases.
7. To achieve minimal headcount and maximal utilization of personnel, the infrastructure maintenance is often delegated to personnel who are also developers
8. Proper and complete control over mobile devices is rarely instituted. With the access to most of the company’s information, an employee can easily transport an entire product source code, contract details or business plan outside of the company

These challenges can cause significant amount of security risks on a daily basis.
I will follow through with the discussion of the risks in my next posts.


Related posts
Personal Data Protection - Anonymizing John Doe

I got invited to attend a strategic meeting at a company specializing in medical software (For sake of confidentiality, let's call them Medic ACME).

Medic ACME needed a strategic position on the requirements presented by a customer for very stringent data protection. According to the presented requirements, the customer wants all patients history in a common database, but insists on minimizing the possibility of a leakage of confidential medical histories. The requirements are as follows:

1. Their general staff (non-MD) must track all procedures and all diagnosis for logistical purposes, but should not see the names, SSNs and addresses of patients corresponding to the diagnosis.
2. IT personnel should have no access to patient personal data (names, SSNs and addresses of patients) even if they dump the database.
3. Upon request of an MD, the staff should be able to type in personal data of a patient to retrieve all medical history for the patient
4. Actual personal patient data must be retained and usable for billing and administration purposes, but only to a very limited number of authorized persons

This set of requirements reminded me of the Payment Card Industry - Data Security Standard (PCI-DSS) requirements for protecting Credit Card data.

Medic ACME proposed to use a reversible encryption of all patient personal data. However, this method requires that the encryption key is common knowledge or at least distributed to a very large number of employees. Also, each access will require decryption of data, and an audit log of each access, thus increasing the load on the database and on the application.

My proposition, which is currently under consideration by Medic ACME was as follows:

1. Copy all original personal data from the Medical database into a separate Patients database together with a reference number to maintain the connection between all medical interventions for that patient in the original database. All data in this database will be encrypted with an asymmetric key (public key encrypts, private key decrypts)
2. Create a unique ID string of data from each patient's name, surname and SSN. In the original Medical database, create an SHA1 hash from each ID string, and replace the original personal data with this hash. The Medical database will now contain a nondescript hash and the internal reference number, so there is no personal data in the database to be stolen or read.
3. Contact a public trusted PKI to issue a strong key pair for encryption. Store the public key in the system, and use it to encrypt all data in the Medical database. Store the private key on several smart cards issued to authorized personnel according to requirements.

This method will permit admission of new patients, with immediate encryption and hashing of their personal data. Also, with this method, it is possible to retrieve patients history by entering it's name, surname and SSN

For billing purposes, a special program needs to be written which will require using the private key for decryption of personal data, in order to correlate them with the medical history.

Talk back and comments are most welcome