Welcome to a module on managing applications the first topic there will be broached seems very obvious
still is extremely vital to all the previous modules provided ample proof that outdated software is
an easy target for automated attacks.
Penetrating a vulnerable system will be neither time consuming nor costly for a potential attacker.
All it takes to takeover a PC is to use freely available tools.
They will see to it in five minutes or less.
Not a great challenge by any means.
As you know programs are not perfect and all that secure a program is an application that has no bugs
or flaws at all.
This is rarely achieved.
To combat this issue software company is really security updates for their products on a regular basis.
Microsoft has throughout the years sculpted a well-designed and seemingly efficient policy in the past
security updates would be released immediately after they were developed and tested.
This meant that an administrator would never know if there would be half a day's work ahead of IMS bent
on testing and implementing potential updates updates were a surprise for both administrators and users
this method was amended some years ago.
Updates are now released in monthly cycles and it's a rare occurrence if an update is released outside
the cycle.
If this happens it means that the bug has already been detected and there are tools on the internet
for delivering an attack that exploits the bug.
Microsoft needs to act at once in that case.
Fortunately this is not a very frequent problem.
Consider the diagram above.
Think about what it represents this in theory is how a cycle of developing and publishing security updates
should look like.
If this strategy is put into effect this would be the best option and an ideal solution for us the initial
point is the discovery of the security flaw in a system.
The person who identifies it should report it.
The information should not be published on the internet but report it to an appropriate software producer.
Many people understand this rule and act on it software producers reaction to a report is a different
matter.
It can be diverse as well.
It might happen that the researcher who reports on the bug is ignored for months and months and only
when the information is finally taken to the Internet.
The producer wakes up to the threat and takes proactive steps to battle it and cooperate with the researcher
when a security critical problem is identified in their software the producer starts to work on developing
and update fixes and hot fixes that aim to eliminate the bug.
At this point we're in the second window of the graph.
The risk that the bug will be exploited by an automated attack is still relatively low.
If you assume a perfect scenario this risk could as well be non-existent.
The only people aware of this problem are the person who reported on it and the software company that's
working to remove it.
Microsoft documents their updates as well.
They are then described in knowledge articles that are publicly available.
The point of this is to give administrators and uses a chance to make an informed decision whether or
not they need to install a specific update by considering if they are directly affected.
And if it detected flaw has bearing on their security policy at the time of release of a knowledge article
an update is also released.
This marks the beginning of an arms race between the administrator who needs to implement the update
in time and eliminate the threat and the people that will want to exploit the bug in other people's
systems.
This is because while source code analysis of office suite of Microsoft Word or of the entire Windows
system is quite time consuming and rarely tried.
A security update is as little as several or several dozens of kilobytes of code
and analysis of this amount is not strenuous.
There are many people who will devote a day or two to study the changes brought about by the code.
If you'll know what problem is eliminated by a given code you'll know the nature of the problem itself.
At this stage we're in the next to last section of the paragraph need to be aware that some of the people
who discovered the nature of the bug the security flaw will try to make use of it.
Thanks to this knowledge they will be able to develop automated tools that exploit a given flaw.
Proof of concept type code would start to appear then the code would then be developed further and be
automated by the same people or by others.
Since the code is now published and widely available the risk is now very high.
Will try to think at the moment how much time has passed until we've got here.
If you haven't eliminated the flaw you're an easy target.
Now to run an attack.
It's enough to open a browser enter a phrase in your favorite search engine.
Download a ready made tool and run it.
That's all there is to it.
Let's now consider briefly the length of time between the outline stages in the race.
As we mentioned reaction time between reporting a flaw and a hotfix and update preparations differs
greatly.
It might take a week but it might take 3 months as well.
This is decided on by a software company entirely.
Statistics show that Microsoft is doing well in this regard.
There are some companies that have known for a year of reported security critical flaws and vulnerabilities
and still have not taken any steps to safeguard their products testing and developing an app that takes
a month in the case of Microsoft.
Why so long.
Operating systems and most of the code provided by this company runs on many copies.
Many PCs have different settings proofing or at least making sure that an update is secure.
Might take a bit long if a swifter reaction is required.
Security bulletins and internal updates are released the updates are not the same as the updates that
are automatically available.
For example at the Windows Update site you can request them online however either by submitting a form
or sending an email.
In this case you will receive a custom security update a custom security update usually eliminates less
popular problems that occur only in some specific configurations or specific environments.
They are not available for everyone because the problem they address pertains to a small portion of
a customer base and because they have not been extensively tested.
In that case a small audience lessens the risk that something will go wrong.
As regards the last part of the graph.
Things get really quick at this point.
Experience shows that there is a day or two no more between an update release and developing a proof
of concept code and exploit automating attack takes another day or even a few hours.
This depends on what the flaw relates to.
Even if it seems you can take time to react there's usually no time to lose.