Testing cyberspace threats

At the time of writing, a two-day international conference is underway in London UK, focused on the threat from cyber-security attacks. It’s true that cyber-security is a threat to the whole online community. We’ve seen a lot of hacks from groups like Anonymous Hackers. These hacks can be used for malevolent purposes, but also maybe for good - like in this video:

 

The Anonymous Hacker Group threatens Mexico's Zetas Drug Cartel to release information on their members. I don’t agree on the things Anonymous does, but I certainly don’t agree with drug cartels. But let’s think of this. The drug cartel is holding an Anonymous member hostage and as a response Anonymous threatens to release personal data on the Zetas Drug Cartel. The result will be that the identity of the cartel members will be made public, so everybody will know who they are. It seems it’ll solve a problem that intelligence agencies cannot solve.

But there’s maybe one question. Who checks the data? Anonymous? What if the data is incorrect? Innocent people will be associated with the drug cartel. And what if an Anonymous member has a grudge against someone like you or me?

But hacker groups like these are not the main threat for most companies. Hacker groups can help companies by showing them the flaws in their systems - and when these companies don’t listen, the hackers try and break in – to prove the point. The bigger problems are the sub groups surrounding these hacker groups. Intelligence is often shared with these groups who have a different (and less well meaning) motivation. They try and break into systems whether on your mobile, your tablet, your laptop, your server or even your data centre. Their objective is to make life miserable for you because they just want to have fun.

In my personal opinion, it’s almost impossible to defend against a group like Anonymous Hackers; if they want to break in, they can and they will. This is the same for your house or office. If a real burglar wants to break in, he/she will. But there are also ‘wannabe’ burglars and ‘wannabe’ hackers. They know only a little but they use this knowledge for their own advantage. But you can keep these ‘wannabes’ out - out of you home/office and out of your systems. But how?

Well there are many ways to keep them out, but before you keep them out, you need to know what to protect. Just a lock on the door isn’t enough. That’s why you need to know how secure your application is. Or how safe it should be. Security should be an essential part of the quality of a business process and should therefore be part of all applications developed. So you need to have insight in the security of applications, and this can be done by testing the security.

Image credits

In the development and maintenance of applications, security should be an essential part of requirements, design and development. And to demonstrate that applications are safe, security should be tested for. Why?

• Users expect good quality and have the confidence that the application is safe. When no insight into the security risks exists it’s not possible to tell this to the users.
• From legislation and rules like Privacy Acts, PCI-DSS, SAS70 or SOx, it’s a requirement that security is in order. The proof for this can be found by executing tests.
• Sometimes it’s necessary to demonstrate that the application is sufficiently safe for various forms of damage. No one wants negative publicity or be confronted with all kinds of claims. Testing shows the status of safety.

Note: Testing provides insight into the quality, but doesn’t improve the application. When bottlenecks are found they are identified and improvements made. 

Testing for security risks encompasses many types of tests or reviews including these options:

• A ‘spotlight security scan’ provides a limited indication of the security of an application. This is a one-or two-day scan on the most critical part of the application, which provides good advice on further steps in application security, particularly to follow-up on any issues uncovered;
• ‘Functional security testing’ has a strong focus on what the application should not do, and looks at how it might be misused;
• A ‘code review’, a static security test that looks at the source code. It can be highly effective because it’s done early in the development process, when the application has not been completed (this is the same with Static Analysis). The code review scans the code to show security weaknesses and when done early in the process, creates awareness among the whole project team and stakeholders which can lead to early improvements and major savings for the remainder of the project.
• A full 'security assessment’ or penetration testing is a thorough investigation that provides insight into the safety of the application., but also the network activity and the infrastructure.

By gaining more insight into application weaknesses it’s possible to keep the ‘wannabee’ out and create a safer application.

Cutting on quality? Or implementing quality?

Greece is almost bankrupt, the US could just be saved from the same outlook and everybody is afraid of a ‘Double Dip’! The World economy still isn’t moving as projected. So there will be a new wave of cost cutting in companies. But is it possible to cut costs even more? As costs across business functions are already as low as possible, cutting more could have a detrimental effect on the quality. And not just for the IT department but the Line of Business owners - what will happen to the quality of software delivered?

An apparently easy option for cutting costs is to cut time taken for testing. Less time for testing, accepting more risks into account when going live, or having less personnel working on tests. But it can also be done differently. How? -  you are wondering!  Well one thing most quality people know is that defects are the cheapest to resolve early in the software development life cycle. Boehm demonstrated, long ago in 1981, that the reworking of defects incurs increasing effort, time and money in proportion to the length of time between the first notification of their existence to the moment of their detection.

But, as we all have known this since 1981, it would seem it’s still too difficult to execute. But now there is a solution: PointZERO®. PointZERO® is a way of thinking and working - aimed at a faster, cheaper and improved software development life cycle process - from the very beginning - at PointZERO®. It focuses on quality, collaboration, continuous improvement and the deployment of tooling and proven best practices.

Unfortunately for many development and testing organisations, this is not immediately feasible in practice. But PointZERO® provides a growth model in a number of steps to optimize this process.

During a project, four types of activities take place separately: Design, Build, Test and Implementation. Traditionally, testing and quality assurance are not involved until the system development well underway and there is ‘something to test’. As a result most quality measures are only taken at a fairly late stage.

But more importantly, good software is an issue for everyone. Implement quality doesn’t just start with testing and QA. Therefore there is a need to go beyond testing and QA - with PointZERO® - to bring together all the IT disciplines.

As indicated above, the four activities can be realigned to meet this PointZERO®. The first PointZERO® step is already taking place in the IT industry; industrialization. But still much can be gained by standardizing processes and using or reusing many new tools and best practices.

A second step is achieving an improvement in efficiency and collaboration. Examples include Agile and Application Lifecycle Management (ALM). Another example is Model Based Testing Services, where functional designs are converted (or drawn up) into models where test cases can be automatically generated.

And the last step is the ultimate process. From the very beginning of the project, testing and quality assurance are structural parts of the whole software development life cycle. Once a business case is made, QA is part of the solution! As for quality control, it means the formal transferral between demand and supply, by using Quality Gates, and the use of modern technologies, like simulation and virtualization methods. This all to reach PointZERO®!

Security: Bubble or a bust?

 

The last few months I’ve been giving a lot of talks around Clouds and Testing. I’ve even published an ebook about it in June – TMap NEXT®Testing Clouds. But the one question that comes up time and time again is “What about security?” And I almost always answer like this: “That’s a very good question! Security of the cloud can be an issue because you are sharing resources from the cloud provider. But can I ask you why this is of such an importance to you? How good is the security of your current application landscape?”

Most of the time there is no answer! Why? Because they really don’t know. Security is something that’s not ‘sexy’, and yet it should be of far greater importance - as all the security hacks of the last months have shown us. Hackers have hacked into a lot of websites, and the best known group is Anomymous. And the hacks that have been executed have been bold, the most famous being the ‘Sony PlayStation Hack’ in April this year.

Security should be an essential part of application development – from requirements, the design and through to realization. It’s possible to implement application safety in every stage of the application lifecycle. A proactive approach to application security is to introduce it as early as possible in the Software Development Lifecycle. An holistic approach ensures that an organization is compliant with the prescribed regulations, has control over application security, and has covered the necessary risks (as cheaply as possible).

What is more, to demonstrate that the applications are safe - they should be tested! Reasons for these tests are:

• Users of applications expect good quality and confidence that the application is safe. Currently this aspect of testing is not normally integrated into standard testing, and therefore there’s a lack insight into this;
• National and cross-border legislation such as ‘Personal Data Protection Act’, PCI DSS, SAS70 or SOX, mean that there’s a requirement to have application security in order. Proving this and its control can be done by carrying out tests and assessments;
• It’s necessary to demonstrate that the application is sufficiently safe to counter various types of damage. No one wants negative publicity or be confronted with all sorts of claims. Testing shows the status of the security.

NB: One further aspect of security. A lot of organizations call themselves ‘SAS 70 certified’. That cannot be true! SAS 70 is an audit using quite a few evaluation criteria. SAS 70 is not a pre-determined set of standards that a service organization must meet to ‘pass’! When you look at the SAS no. 70 FAQ website, there is answer to the ‘success’ or ‘no success’ criteria. When the service auditor concludes that the above items have been accomplished, the service auditor renders what is referred to as an "unqualified opinion." While a SAS 70 audit is technically not a ‘pass’ or ‘fail’ audit, the receipt of an “unqualified opinion” from the service auditor is often referred to as ‘passing’ the audit.

So the service auditor's report contains the audit opinion, the organization's description of controls, and a description of the auditor's tests of operating effectiveness. It doesn’t set (nor is there any) SAS 70 certification!

 

Cloud cracks; break down or support

Last week we all heard about the failure of the Eastern US data center of Amazon’s Web Services (AWS). And now there’s more negative talking about the cloud coming up. The cloud is certainly starting to show its cracks.

But is this a bad thing? Is it a not good thing for the cloud’s image that it wasn’t reacting more so than multiple sites and services, like Reddit and Foursquare, that went down? No, it’s not! For the first time we’ve seen what can happen when the cloud fails. And we can now keep it in mind when creating these services and we’ll know what to do when it happens again.

As this excellent post by Scott Gilbertson on Lessons From a Cloud Failure: It’s Not Amazon, It’s You indicates, cloud users should “design with failure in mind”. A cloud is also software and software can fail. But everybody was on ‘Cloud 9’ with the cloud and only the pessimists were talking about cloud failures. Now they’ve seen what can happen and they can prepare for it. Not only the cloud providers like AWS, but also the owners of those cloud services.

Cloud providers and brokers should have recovery mechanisms in place in case of a disaster. According to Gartner: “Any offering that does not replicate the data and application infrastructure across multiple sites is vulnerable to a total failure.” Cloud providers should have guidelines concerning business continuity planning, detailing how long it will take for services to be fully restored.

Again, according to the research firm Gartner, the cloud market will grow to $102.1 billion next year. Companies will continue to weigh the benefits of the cloud, its massive cost savings and easy scalability, against the relatively small risk and annoyance of outages - risks and annoyances that could also have happened with a failure in their own non-cloud data centers.

The level of cost savings gained from moving to the cloud depends on all kinds of variables. The study by Booz Allen Hamilton The Economics of Cloud Computing in 2009 found that "the benefit-to-cost ratio of a non-virtualized 1,000-server data center could reach 15.4:1 after implementation, and total life cycle cost may be 66% lower than maintaining a traditional data center."

In the AWS case, luckily nothing catastrophic happened; no private data was lost or ‘left on the street’. So everybody can sleep well. However, this failure helps to build the hype around the cloud into a more supported use of its services. The failure doesn’t make cracks in the cloud so it’ll break. But it will make cloud construction better and we will be able to enjoy the benefits even more in the near future.

What I would say is that Amazon, other cloud providers and their cloud customers will learn from this outage, because these savings from cloud are simply too great to dismiss, and they will keep the customers coming.

Education Construction with IT experience

I was just driving to the office when I heard some news on the radio: “The rebuilding of the Stedelijk Museum in Amsterdam will cost a minimum of 4,5 million Euros or more!” This for a museum that has been closed to the public since 2004? 

In construction it’s acceptable to be late and more expensive. If I look at other construction projects in the Netherlands – they are all way over budget: the High Speed Train (HSL-Zuid) 6,7 billion Euros instead of 3,4 billion; the Metro in Amsterdam (Noord/Zuidlijn) 3,1 billion Euros instead of 1,46 billion.

And these are only the tip of the iceberg. If you look good at big construction projects, you’ll notice that a lot are not on time and not within budget. And after construction has been ‘delivered’, even then there are still issues in the construction that need to be fixed.

So why do we try so desperately to finish IT projects on time and within budget? And why is it acceptable within construction to exceed the budget?

Source: Het Parool

IT tries to do everything to be on time and within budget, but appears to fail.  The reason for this disparity is partly because the planning of these construction projects has already have taken into account time lapses like weather, equipment or working conditions. For example if a project can be done within 1 year, the contractor will say it will be done in 14 months with 10 winter days.

Another reason is that the time or budget overruns happen with big construction projects. The smaller ones are less influenced by changing prices, the weather, politics or working conditions.

So if we plan IT projects with less tight planning constraints/parameters and only implement short projects, we’ve found the answer. Right?? Unfortunately not! Why construction can still deliver to an extended timeline is a question for me that I cannot answer.

But for IT, that time of extended timelines has passed. We could do this before the ‘Dot-com bubble’, but not anymore. And now with the advent of cloud, we’re even saying that IT will fulfill its promise to the business and create business technology.

We in Quality are always saying that we want products that are as good as needed. We use different processes to create the best product, like work processes, documentation reviews, code review and testing.

So how can we apply the lessons that we’ve learned in IT to the construction industry? What I’ve seen in the Netherlands is that the Dutch Government is asking their (building) contractors to look more to quality and hand out fines when plans aren’t met. We at Sogeti are even testing construction sites like tunnels. Maybe, despite the thousands of years of experience in construction, we in IT can help - with what we’ve learned from the last 20 years?

Apple: Use a test technique/A test of Time!

At the beginning of 2011 the hottest technology topic in the news was the alarm clock bug in Apple’s mobile appliances - iPad, iPhone and iPod. For January 1 and January 2 in this New Year, the Alarm Clock application wasn’t functioning. The same problem happened a few months ago when Daylight Saving Time was set in  October 2010.  The issue is with the ‘repeating alarms’ - a software bug in Apple’s software, iOS.

Courtesy of http://www.flickr.com/photos/helionorio

Changing the time

I would like to help the test manager at Apple with the necessary testing  he/she needs to get executed to find this fault in their other software. Because the bug appears with specific time changes; Daylight Saving, New Year, etc; . it looks like an error in specific Equivalence Classes.

OK, but what is an Equivalence Class? According to TMap NEXT®, it’s “the entire value range of a parameter partitioned into classes, in which the system behaviour is similar (or equivalent)”. Other terms used to refer to the design of test cases based on equivalence classes are ‘equivalence partitioning’ and ‘domain testing’.

Why should I use equivalence classes?

Well, as it happens at these specific time changes, you can set these time changes in a value range of a parameter, a class. Within this class, the behaviour is similar; it generates a bug so the alarm doesn’t go off.

How should they test this?

Apple should be using a test technique called the Data Combination Test (DCoT),  a versatile technique for testing of functionality both at the detail level and at an overall system level. In the embedded world, this technique is also known as the “Classification Tree Method”, was developed by Grochtmann and Grimm.

The fact that domain expertise is usable as a test basis also makes this technique suitable for situations in which specifications are incomplete or out of date, or even unavailable altogether. Time changes!

Test the load of Skype?

The last few days Skype has had trouble getting their users connected to their online phones service. The reason being too many concurrent users. That enormous amount of users gave Skype problems; the Supernodes were offline because of a software bug. Now I can say that they should have tested for this defect, but how do you test for a defect that occurs with about 25 million concurrent (online) users, the typical load for Skype on a regular day?

A load test could have found that defect, but how do you organize such a load? Normal load testing software doesn’t have the  option to go as high as 25 million (!); most will only get to 100,000 virtual users. And even if these tools reach these high volumes, virtual users will be very expensive. So how can these internet services, that have so many users, be load tested?

The cloud can provide an answer. Load testing tools that use the cloud can generate an enormous amount of virtual users to create that load, and cloud-enabled test tools are best to use with these great loads. The cloud will generate the load. With the use of the cloud infrastructure, a more ‘realistic’ load can be generated than the virtual load from complex tools. Some of these cloud-enabled performance test tools only work on the production environment (which may or may not be in a cloud environment), but other tools can perform these load tests on the Development, Test or Acceptance environments.

Use these cloud-enabled performance test tools to generate these enormous loads and find defects that only show up when your systems are most under stress. Thus at the worst moment!

  

Testing for WW III?

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The mushroom cloud from the Fat Man nuclear bomb dropped on Nagasaki, Japan on August 9, 1945.

---

[1] [Note: Petrov considered the detection to be a computer error because a US first-strike nuclear attack would be most likely involve hundreds of simultaneous missile launches in order to disable any Soviet means of a counterattack. Moreover Petrov, as an individual, was not in a position where he could have single-handedly launched any of the Soviet missile arsenal. His sole duty was to monitor satellite surveillance equipment and report missile attack warnings up the chain of command where, ultimately, the top Soviet leadership would have decided whether to launch a ‘retaliatory’ attack against the US.]

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III. The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

The tensions between North and South Korea may have been eased, but the last few days have shown that there still is a Cold War on the Korean Peninsula. The North Korean Government said that the live-fire naval drill could be explained as an act of war between the two countries. And as this maybe the most dangerous place on earth because of the nuclear weapons both countries have, we can only hope that their software for detecting real strikes has fewer defects than the software the Soviet armed forces used in 1983. Then a defect in the software could have unleashed WW III.

It is September 26 1983. Tensions between the USA and Soviet Union are at a high because of the shooting of a South Korean passenger jet by the Sovjet Union, killing all 269 people on board. That night, the Soviet early warning system, code-named OKO, reported an intercontinental ballistic missile heading toward the Soviet Union from the US. Standard Soviet protocol said that if the notification of a missile launch was detected by this system, the strategy was an immediate nuclear counter-attack against the US.

So, shortly after midnight the system detected this missile heading towards the Soviet Union. The lieutenant colonel who was the officer on duty, Stanislav Petrov, considered the detection as a computer error - a defect. Petrov dismissed the warning as a false alarm. Later four more missiles were detected and again Petrov suspected a ‘defect’ in the system.

Luckily for us all, Petrov was correct, there were no missiles launched[1]. This was lucky because Petrov believed correctly that the system was too prone to bugs and defects so that any warnings would be false warnings.  It would appear that OKO’s test strategy was not correctly analysing for the appropriate risks and critical defects were still in the system.

Today most countries’ defence systems have made significant progress in producing software that can be trusted – be can this be said of all countries?  Double guessing whether a notification of a missile launch is either exactly that or a software defect is a risk no country should be taking. 

Does the Cloud also provide Security?

WikiLeaks and its founder Julian Assange were very high profile in the news these past weeks. And there are some problems surrounding WikiLeaks, payments and DDoS attacks. For now DDoS attacks cannot be repelled, but maybe WikiLeaks has found an answer.

After the news that PayPal, MasterCard and Visa were not allowing any money transfer to WikiLeaks, this because of a criminal investigation of Assange in Sweden and the unveiling of US Foreign Office diplomatic documents. After these organizations were not allowing any payments to WikiLeaks, they were hit by hackers with DDoS attacks. DDoS stands for a distributed denial-of-service attack on webistes to make them unavailable to its potential users. As a result the sites of MasterCard, Visa and PayPal were unavailable; they went 'down'.

Commonly a DDoS is done by saturating the target machine (the website) with external communications requests. As a result the target cannot respond to the traffic, or responds so slowly as to be rendered effectively unavailable. It consumes the target’s resources so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

WikiLeaks also gets hit a lot with DDoS attacks, but they have thought of an answer to these attacks; they moved their website into Amazon’s EC2 cloud. As only the website itself has been transferred to Amazon, for now the data is hosted in France, the US government cannot make any rights to the data. With this solution WikiLeaks hopes to fend off any attacks on its website. As the cloud is elastic it can absorb the saturation by adding extra services from the cloud. As a result the capacity of the website will not be totally consumed and will keep functioning accordingly. The cloud helps in security by making sure the website has continuity, instead of being a security risk!

A winter Cloud

The last few days the Netherlands have been seized by Father Winter. Global warming at its best? Or just a cold end to 2010?  Fact is that transport systems have had problems with the snow and ice. I myself got stuck in Dublin at the start of this month because of the winter weather. But not only are flights cancelled, public transport comes to a halt and we all get stuck on the freeway for hours, the websites of these transport organizations are unavailable due to heavy traffic. As a result, people are not available to get information about their transport and don’t know what to do.

 

The websites are getting so much traffic from people looking to see if their flight is still going, rebook their cancelled flight, check the times of delayed trains, find out about the traffic jams before they leave, or what roads are closed due to ice and snow. All this information becomes unavailable. But what is the solution to this problem?

The websites are unavailable because they are not prepared for that amount of traffic. They haven’t enough bandwidth and servers available; they are not scaled to cope with this volume of requests. However, if the websites were in a cloud environment, they could have this scalability…. just by adding more services when the available amount of services gets to a critical low.

This would not only help in this winter, but also for airlines during the ash cloud in Western Europe, due to the eruption of the Eyjafjallajökull volcano. A cloud offers websites the necessary scalability!