"If it ain't broke, don't fix it" - A fundamental downfall why defense-in-depth isn't always effective

Yes. I know it is sound too familiar to most security professionals when they propose a new or better way of doing things to their colleagues, sometimes management level with a variety of facial and body language responses.

This is especially true on occasions you are telling them to update something that you know vulnerable to external/internal exploitations. Here are most common feedback you will get in no particular order.

• Systems are not accessible from outside, only authorized personnel can use within office
• Certain bespoke LOB software is tied to particular version of OS, framework, application and vendor cannot guarantee to work with newer versions
• SLA is too demanding that they can't afford to have any downtime
• No allocated budget

As much buy-in as you need to implement those updates, your first and foremost task is to convince them which can be easier said than done. Let's take on one feedback at a time.

1. Systems aren't accessible from outside. Really, really? It's time to re-think which business systems are exposed to external world, like websites, emails, attendance systems, ERP systems, and better yet, SSH access for mission-critical infrastructure devices. Unless these services are protected behind VPN, each of them are waiting to be probed and attacked. There are plenty of reports like Internet Census 2012 reveals how many of service ports are visible on public internet. With a right tool like SHODAN, sky is the limit of which you can or cannot access. Based on Akami's State of the Internet report for Q2 2013, ports 80 and 443 had topped previous leader port 445 over 41% vs 15% as most commonly targeted ports.
2. Customized CRM, for example, can't be updated as it may have several dependencies to OS, framework and application versions. Isn't it the reason why we pay a great deal of money to application vendor for maintenance? Well, sometimes it is truly confusing to understand what really was in the agreement. Off-the-shelf software scores a point in this area as they are continually updated and checked for compatibility.
3. Every business has its own commitment to its users which we understand as SLA. This is one good example by Google Apps. Given that, even organizations with highest SLA level could have downtime inevitably. But we do have necessary measures to minimize downtime. All critical changes are required to go through development, UAT then production environments so that most possible problems will be taken into account for business continuity.
4. After considering above facts, it shouldn't take too long to get financial backing. The way we see it, most updates come free and most BCP are in place so there won't be much requiring special budget.

So, why do I give this title and what motivated me? I can understand there are already so many things on system/network administrators' plate to handle day in and day out. Any new changes could take additional time on their busy schedule. So think of other way around. All those miscreants are trying to break what administrators try to keep in working order and they will find one way or another to do just that. So why don't we preempt by implementing known fixes in advance? Should anything happens, we have backups to rollback and try with other methods. If anyone were to break the our systems, it would have been better to be by us than some random hackers creating headlines.

B&B for Personal Computer - Baseline vs. Benchmark - Security and Performance

It comes up naturally that someone asks you how to keep the computer fast and secure, be it as part of conversation or knowing that you are considered a geek to them. In order to answer their question, you may shoot a response something like 'Do you know how many applications and how often do you use them?' As simple as it seems, most of the people I know begin to mumble once I ask this.

When we talk about enterprise security and performance, we all accept the fundamentals of keeping inventory of software and hardware to gauge application response at a given time using various monitoring tools.

But do we really (really) apply this knowledge to our home computers, let alone casual users in question?

The honest answer: No, we don't.

Now, let me share how I've been keeping tracks of these things. Back in the days, we've used mechanical disks as our primary storage and there were plethora of applications we installed on our systems. At the time, I usually rated my computers' performance by how fast I could start using after powered on and I did compensate some time to the factor due to mechanical disks; the average was 90-120 seconds. I had about 40-60 installed applications, 15-20 start-up programs and 25-35 auto-start services. I was literally very patient person back then.

When I jumped on the SSD bandwagon last year, I was still skeptical to whether I should adjust my previous computer benchmark just because of the speedy SSD and 1600MHz DDR3 which I standardized across the board. Finally I decided to set a new benchmark: 40-60 seconds with similar number of applications, start-up programs and services. I became a not-so-patient person after all.

So what am I trying to say here? Only two things: what do you really need to use and how fast do you want them to perform.

Baseline:

• Never install software that you may never use. Even if you pay for the software, install only when you need to use them. Leaving unused software on the computers not only take up storage but also affect system performance. For example, Java. Keeping them could only do you harm with never-ending vulnerabilities and lagging timely fixes. 
• Check your software vendors' EULA how they track software usage for you to have the flexibility of install/uninstall choices.

Benchmark:

• We can easily check any start-up programs and services using Windows tools or other readily available tools like CCleaner, Sysinternals, and remove any unnecessary programs to prevent loading at start up.
• You may have a number in mind, say 30 seconds to start using the computer. Make sure the number is reasonable based on your system components' specification and be mindful of compromises you may have to accept.

By now, you should see where this leads. Having a baseline of application and benchmark can help you achieve higher security and better performance. Think about the time you would save to update those applications in addition to normal Windows updates. With less software installed, you can finish patching faster and maintain a shorter list of auto-start program/service.