Yesterday, I gave the main disadvantages of Patch Tuesday so today I thought I would take the other side of the argument. Is Patch Tuesday good for your organization? Ultimately, it depends on the enterprise and its unique operations – but I can highlight some of the advantages as well as the concerns.
Patch Tuesday was started by Microsoft who started releasing patches for its Windows operating system, associated components, and Microsoft office products like Office, Visual Studio, and SQL Server, in 2004. Since then, other vendors followed suit and now we have every second Tuesday of each month to look forward to new vulnerabilities simultaneously announced and fixed.
Now there are a few advantages to the Patch Tuesday system of updating:
1. Avoiding ‘Exploit Wednesday’ or ‘Day Zero’ is a big weight off your shoulders. Because software vulnerabilities are announced and fixed on Patch Tuesday, attacks that take advantage of this information to attack unpatched systems occur the very next day, usually called ‘Exploit Wednesday.’ Our new culture of Patch Tuesday has inadvertently created a rhythm of patching and attacking on the second Tuesday and Wednesday of each month. At this point, security administrators have almost no choice but to comply with this rhythm.
2. Patch Tuesday simplifies patch management for system administrators. Instead of manually checking for patches or allowing unplanned updates disturb workflow, enterprises can schedule for and adequately plan this time for patching their software. Since the Patch Tuesday trend started, people are much less likely to forget to patch since they plan for it each second Tuesday of the month.
3. By installing multiple patches at once, you can update all your software with a single reboot. It may not sound like much since reboots can take only a few minutes, but multiply that by 10 or 20 and that is a lot of downtime and lost productivity.
Now, even with those advantages I don’t know any organizations that simply install patches right away, you would be nuts,
Whenever executives discuss IT and cost cutting, invariably two topics come up: Virtualization and the Cloud. Don’t even get started on the topic of the cloud, and the chance for rain. Virtualization is a good topic to discuss since some items may be unfamiliar to you (especially those in the SMB).
By now, most companies have adopted, or at least looked into, overhauling their IT infrastructure with virtualization solutions. Virtualization is said to reduce costs, simplify management and scalability, and limit the toll computing has on the environment. Since 2005, virtualization software has quickly changed the landscape of enterprise computing.
For those unfamiliar with the concept, virtualization involves abstracting computer resources by combining several physical systems into virtual machines on one powerful system. Virtualization consolidates underutilized hardware, such as servers, storage devices, and network resources, virtually partitioning it for multiple machines.
The reason virtualization has become such a favorable trend in IT computing is probably because the advantages are so easy to grasp. First of all, the physicality of managing hundreds of machines is simplified while allowing for a scalable infrastructure. Plugs and cables do not have to be rearranged every time there is a change in hardware. This reduces the workload of the system administrator. Virtualization allows hardware resources to be pooled such as sharing storage or network bandwidth, so hardware does not go underutilized. Less hardware means less energy costs, both to run and to cool. Altogether, these advantages lower the costs for infrastructure, hardware, power, and cooling.
You’ve probably had the green benefits of virtualization stressed to you. According to VMware, for every server virtualized, you can save about 7,000 kilowatt hours, or four tons of CO2 emissions, every year. Virtualization can cut the power demand of ten machines down to one and save almost 80 percent on an electricity bill. VMware even has a green calculator on their website which allows you to see your virtualization benefits in terms of energy savings, cost reduction and environmental impact. A quick calculation shows that virtualizing 200 servers is the equivalent of planting 4,000 trees.
Of course, businesses are more concerned with reducing costs than reducing the size of their carbon footprints. With this in mind, there are a few disadvantages, or at least pitfalls, that may be created with a switch to virtualization.
But there is a down side – it is likely that performance degradation will occur when switching to a virtualization infrastructure if the virtual infrastructure was not properly architected. (which seems to be the case all too many times we get involved). In most organizations there is often a lack of tools and expertise available to monitor and analyze virtual environments to find and correct issues that affect performance. A study by Aberdeen shows that enterprises that had an 85% success rate in identifying performance issues in a physical environment, now only have a 37% success rate in a virtualized one. Also, improved response time for managing business-critical applications fell from 67% in a physical environment to 39% in a virtual one.
Many enterprises find that there is a tradeoff between decreased staffing and power costs and less than optimal performance. Sometimes this means that the advantages manifested by virtualization are less than expected so ensure you have adequately measured the minimum performance requirements for your infrastructure before you go run off and virtualize everything.
With the end of 2009 approaching, cybersecurity engineers as well as cybercriminals are looking to next year to see what the future of internet security holds. Where will current cybercrime trends go and what new ones will emerge? Well, here are a few of my predictions on what virtual mines the Internet landscape will have in 2010.
Emboldened Social Engineering – This should be no surprise to anyone in cybersecurity or who has read this blog before. In 2009 cybercriminals realized that social engineering is the easiest way to obtain sensitive information from users. And while social engineering was big this year, it will continue to grow exponentially next year. Expect social engineers to become more organized and bolder in their methods. There may be more incidents where social engineers visit sites physically to gain trust and information that no software can physically protect.
Social Networking Sites Will Become a Bigger Target – Social networking sites like Twitter and Facebook are only gaining popularity and no amount of security warnings are going to keep users away. Cybercriminals will use these sites to their advantage in two ways. While I believe the sites themselves will become more proactive in creating security defenses, the third party applications made for these sites will have exploitable vulnerabilities. Additionally, social networking site users will increasingly become the victims of social engineering. These sites give social engineers a terrific medium for contacting, communicating with, and taking advantage of users.
Ransomware Will Replace Scareware – Hijacking a users PC and holding it for ransom may seem outrageous, but it’s happening now and proving to be more profitable than scareware tactics that users are now growing wise to. Expect cybercriminals to go where the money is – users would rather pay a small price to regain control of their PCs than go through the trouble of manually removing malware – or nuking their PCs.
Mobile Devices Will Be Hit Hard – Mobile phones have enjoyed their short lives mostly free of threats while continuing to propagate. But now that they have increased in complexity, becoming mini notebook computers, the likelihood of vulnerabilities has also increased. 2009 saw the Sexy Space botnet and the iPhoneOS.Ikee – what awaits our precious smartphones in 2010?
Organized Cybercrime – The cybercrime underground has evolved into an elaborate economy where, in 2009, cybercriminals have begun to network, collaborate, and pool resources for mutual gain. Malware infected PCs and botnets are bought and sold like commodities. I expect this trend will continue in 2010, and it may be the most dangerous prediction. Combating such cybercrime organizations will require the same organization among security experts.
A popular blog article on techrepublic categorizes the five reasons to kill IT projects. While it has inspired a lot of input from the IT community, I thought I would do my part by adding something helpful. We all have an idea why IT Projects fail, but what could be done to actually save IT projects?
Cause of Death: “Business need changed” or “Project was no longer a priority”
It’s an obvious one, businesses always change – perhaps more frequently now than ever. The defined requirements for an IT project may be integral at one point, but later be unnecessary. Thus losses are cut, and the project is killed.
Project development is not agile enough to meet the changing needs or priorities of a business. Saving these projects from growing stale requires fast delivery. But since unrealistic timescales cannot be achieved, the trick is to split larger systems into separate, smaller projects. This way, each small project can be finished within a timeframe that keeps it in alignment with the needs of the business. Then, the next small project can be reevaluated based on the current needs.
Cause of Death: “Did not deliver as promised”
Self explanatory: expectations are set up, vague promises are made, but somewhere along the line, the result does not match requirements. Sometimes managers exaggerate the functionality of the promised project in order to get funding and worry about the consequences later.
Other times, it’s simply a problem with poor or no requirements. High level, vague, and generally unhelpful requirements lead to situations where a gap widens between user expectations and project goals. IT specialists are sometimes working blind with nothing to guide them. It’s a common break down in communication; one that we see in the IT field on a daily basis.
Cause of Death: “Project exceeded the budget”
It’s far too easy to use budget performance as a simple metric of success or failure. Situations are far too complicated to dismiss a project for this reason alone. Often projects that run over-budget are the victim of scope creep.
Scope creep usually grows out of, again, poorly defined requirements, where management decides to tack on additional functionality during the life of a project. Usually these additions are made because requirements were simply not carefully thought out in the beginning. An increase of scope, of course, affects time scales and budgets.
Cause of Death: “Project did not support business strategy”
Changing business needs or poor requirements often result in the misalignment of project goals with business goals. As we clearly understand by now, businesses always change and this can make some current project obsolete. While it is not realistic to expect no change in requirements while a project is being built, it is also unrealistic to expect a project to adapt to changing requirements and goals.
But that does not mean these projects must suffer a miserable death. Useful projects employ change control systems to effectively allow for changes in requirements without trashing the entire thing. Change control systems emphasize shorter timescales and a phased approach to building systems so that change does not disrupt development as much. Change management must then evaluate the effects of changed requirements on the timescale and budget.
Portfolio Rationalization appears to be one of the trendy new cost-cutting initiatives of 2009 and its ubiquity resonates from the internal IT departments to IT outsourcing strategies. With budgetary restrictions on the forefront of our collective unconscious in this current economic environment, I thought this would be a good time to point out some of the opportunities afforded by IT portfolio rationalization that may benefit your organization.
IT portfolio rationalization is not a complicated practice, although it has been evolving since the late 1980s as we attempted to use the lessons of financial portfolio management to justify, measure the benefits, and compare the costs of IT applications and resources. It involves taking inventory of your IT components, justifying the need for them, looking at the cost versus benefits, and reconsidering how these components could be supported with less cost.
It all comes down to reducing costs while improving productivity. The idea is to trim down unnecessary IT spending, consolidate redundant IT resources, discover misalignment between business strategy and IT strategy, and optimize IT operations.
1. Reduce costs by consolidating technology portfolio components and applications. The larger an organization becomes, the more redundancy can be found. Is your organization licensing different applications from vendors which perform the same functions? Are you using multiple vendors for similar products when you could rationalize these products into a single offering from one supplier? These are areas where you can easily hack off some fat.
2. Are your outsourcing resources delivering cost benefits to the current needs of your organization? Things change. Long term agreements with outsourcers may originally make sense, but as the shape of your organization changes, your outsourcing portfolio can also experience redundancy or simply misalign with your business strategies. What outsourced components can be brought back into your own IT function? Can you reassess your outsourcing partners and consolidate them into a single provider? Analyze the most cost-effective way to support a portfolio component and reconsider your outsourcing relationships.
3. Mergers and acquisitions lead to tremendous and sometimes chaotic growth within an organization. During these times, organizations may not have the time or resources to consider simplifying the new IT portfolio components they have acquired. If your organization has recently undergone such a transformation, then you have an opportunity for cost savings and operational efficiencies through portfolio rationalization. Beware the expression, “if it ain’t broke don’t fix it” – sometimes things that are unbroken can still cost us needlessly.
If you run an IT organization and have not had a chance to look at the new Federal IT dashboard, take sometime today and look at it. The transparency that our new Federal CIO, Vivek Kundra, built is great! We, the American People, the investors if you will, are now able to see the performance of our investments in the US government. I have always touted transparency for IT and now project by project, each CIO within the government is required to report progress on all of their projects to the public.
Amazingly, Vivek only gave the CIOs 30 days to get their information up to date and even more importantly, since the IT dashboard obtains its information from the Office of Management and Budget (OMB), the agency CIOs have to not only update the information but update it through the proper channels for it to be placed into the dashboard.
With one simple portal, Vivek has increased the use of the standardized project management frameworks in place throughout the government, increased the accuracy of information, and has helped create a sense of urgency and fiduciary responsibility for each agency CIO because their performance is now open for all to see. Similar to posting your review for all to see on the company bulletin board, we have advocated that public access to information increases the chance that an employee will “do the right thing” For example, we recommend that when you are starting to deploy change management processes internally that any person that bypasses the change management controls and introduces an outage have their picture posted on a company wiki, sharepoint portal, etc as the “wild wild west cowboy” that “caused the problems”.
A little bit of public humiliation may be just what we need to get the governments IT projects back on track! Some examples:
Oh, and in case you were wondering…many(over 30%) of the governments IT projects are behind or in need for serious help.
Check out Tim O’Reilly’s blog post about the Federal IT dashboard for more information on how it was constructed and how it receives data.
Consider this: A hacker finds a security hole on your website that exposes hundreds of thousands private customer data including names, emails, and even passwords. The hacker does not steal this information. Instead, he quietly alerts you via email; but at the same time he makes the security vulnerability public information on his blog.
Do you: A) Thank the hacker for bringing the security vulnerability to your attention? Or, B) seek legal action against the hacker who damaged your company’s reputation by alerting the public about your sloppy security?
This is the controversy surrounding “HackersBlog.org” – a blog where anonymous hackers alert the public about security vulnerabilities. Each blog entry lists the site hacked, how the data was captured, and what private information is accessible.
The site made its first splash when a Romanian hacker named “Unu” hacked the databases of Kapersky – ironically, one of the leading companies in the security and antivirus market. “Seems incredible but unfortunately, its true,” writes Unu, “Alter one of the parameters and you have access to EVERYTHING: users, activation codes, lists of bugs, admins, shop, etc.”
The next target, which occurred the very next day, was BitDefender – another antivirus software company. Unu used an SQL injection to show how data could be easily extracted.
In an official statement, Kapersky denied the attack was successful. BitDefender called the hack an attack and portrayed it negatively even though “the action did not intend to steal information but simply show a vulnerability.” Usually when sites are hacked, the companies are left scrambling to put out the public relations fires.
So, alerting the website via email about the found vulnerability? That sounds white hat enough. So why expose the flaw to everyone publicly on the Internet and wreck the reputation of that company? “If we just send an email, without making it public they would fix only that parameter that we announced,” says Unu, “and it is possible [for there] to be others too.”
It seems that HackersBlog owes its allegiance to the public and not to the companies who allow for these breaches in security. “I’m not a criminal, I [am] not a burglar,” says Unu, “You do the work of a [pentesting firm] that could test the security of the site or [sic] server at the request of the owner. The difference is that the firm makes this for a big sum of money, a very big sum of money, and we do it as a hobby, for pleasure, free, and most of the times we do that much better, but we don’t even get a simple ‘Thank you.’”
Leave me a comment and let me know what you think about this Hacker Blog site!
The reality of the situation is that there is no such thing as a 100% secure place on Earth. IT security professionals can only do what they can to make things as secure as possible. There is no computer security defense that will succeed every time, forever, or as I say when presenting at conferences “You cannot buy your security at the local best Buy”. (NOTE: If you have an indepth udnerstanding of heypots, you can skip this post)
Because of my interaction and association with the Honeynet Project I am frequently asked what benefits honeynets can provide to the normal everyday IT security engineer. Simply put, honeypots provide us with early warning so we can be vigilant and prepare our defenses accordingly.
Additionally, honeypot data is a great way to loosen the purse strings of corporate managers who are hesitant to dip into the company budget. You can make a case for a larger IT security budget by showing them the attack data on the honey pot – who is attacking, how they are attacking, how often, and, most importantly, what damage they could potentially do to the enterprise if the proper defenses are not built. Actual data speaks louder than any verbal argument.
Here’s an analogy to help you understand the importance of honeypots.
Imagine you are tasked with defending your king’s castle from an impending enemy attack. But you don’t know who the enemy is, where they are coming from, how many there are, or what kind of attacks they will use. They may use spears, rifles, or just sharp rocks. They may attack on horseback, with catapults, or maybe with tanks.
So what kind of defenses should you build? A 30 foot tall wall surrounding the castle or a moat? Should you put archers in the towers or build turrets? Maybe you should just pile up a few sandbags and hope for the best. Maybe the real problem is the village idiot on the inside… =)
Without knowing anything about the impending attack, you do not know what an appropriate defense would be. You may dig a futile trench around your castle while the enemy attacks with stealth bombers. Or you may encapsulate your entire castle in an impenetrable crystalline dome while your five attackers sling rocks at it. The latter defense may work, but your king might not be too happy with you for wasting his whole treasury on an unnecessarily robust defense.
A Honeypot is perhaps like a decoy paper version of your castle set up a mile before your actual king’s castle. The paper castle has no value, but you can see what attacks your enemy uses when they attack it, and thus prepare accordingly.
Honeypots allow you to understand what kind of attacks you can expect. With this knowledge you can allocate resources to defenses appropriately, without under or overspending. Now, with all that said not everyone can run out and install a honeypot and solve their problems. Honeypots require a lot of maintenance, watching, and i fnot properly installed you can actually decrease the security of your network.
If you don’t want to take the chance of hurting your own security posture, there are services that will configure and run honeypots for you and provide you with their data. Symantec and McAfee offer such services.
The ramifications of the billion dollar fraud at Satyam in India are far-reaching indeed. Not only is the future of Satyam in jeopardy, but the ripples from this incident will spread over all IT outsourcing in India and, to some extent, all outsourcing in foreign countries.
The Satyam chairman’s confession that he falsely inflated the firm’s revenue is really India’s first scandal of global significance. But the financial service firms that relied upon Satyam for integral business operations have been burned badly.
And these lingering burns will cause additional hesitation when considering outsourcing to foreign countries. The country of India itself will have to work hard to maintain its clean image in light of this scandal of Enron-esque proportions. The enticing shimmer of inexpensive IT services overseas has lost some of its luster.
With 600 customers in over 60 countries, the global impact of the scandal is sure to be echoed throughout the world. Even the international football federation FIFA enlisted Satyam to develop an event management system for $200 million.
The future of Satyam does not look good. Usually when we see a breach in customer trust of this magnitude in American firms customers flock to competitors the first chance they get.
What better time to remind companies about the importance of performing due diligence on their outsourcing partners? I recently saw a study that said that fewer than 43% of financial services companies undertake any form of due diligence when considering outsourcing partners, even though 46% of them believe that outsourcing is a way to achieve business transformation and a competitive edge. I wonder how these numbers will change post-Satyam.
Often companies attempt to mitigate the risks of outsourcing by using larger vendors. The fall of Satyam, one of the largest vendors out there, should teach us that this is not an effective strategy. An effective due diligence procedure is the best way to mitigate the risks of outsourcing.
