Reducing the attack surface in Adobe reader is an important step in reducing malware attacks. The vast majority of all PDFs do not contain Javascript, but Javascript-embedded PDF files is a well known method used to attempt to compromise end user systems. This can occur in phishing scams where e-mail messages contain infected PDF files, or links point to infected PDF files hosted on web sites.

Adobe Reader on Mac. Click for full size image.

Here is how to block Javascript in Adobe Acrobat 10 for Mac. Go to Acrobat > Preferences > Javascript and uncheck Enable Acrobat Javascript.  Then click OK.

Similarly, in Adobe Reader X on Windows, go to Edit > Preferences > Javascript and uncheck the Enable Acrobat Javascript, then click OK.

Likewise, for Adobe Reader 9 on Linux, go to File > Properties > Javascript and uncheck Enable Acrobat Javascript, then click OK.

Adobe Reader on windows. Click for full size image.

Click the thumbnails to view screen shots for Mac, Windows, and Linux.

Adobe Reader in Linux. Click for full size image.

Guest post from Casper Manes on behalf of IT Channel Insight

Whether you are a commercial pilot, an astronaut, a submarine weapons officer, or a Cylon, you know the importance of having a plan. There are certain tasks that, no matter how repetitious they may seem, are so important to get right the first time, and every time, that they have been boiled down to a checklist which any reasonably skilled and trained individual can walk through, step by step, in order, to accomplish the task. They are designed to be easy to follow, to spell out exactly what needs to be done, and the order in which it must be done, to get things going, and to require a minimum of creative thinking. Tasks are performed by rote, and verified each step of the way. That’s the perfect way to approach disaster recovery, and in this article we’ll discuss why you need a disaster recovery plan that is a little more detailed than “don’t panic!”

What is a disaster?

Let’s consider what, in business terms, can constitute a disaster. Sure, things like hurricanes and blizzards come to mind, perhaps even fires in the datacenter, but a disaster is more than just a weather phenomenon or catastrophic loss; it’s anything that significantly disrupts the normal operations of your business. If we limit ourselves to an IT perspective, that can include prolonged Internet outages, a severe flu epidemic that takes out half the staff, a virus that shuts down key servers, or a SAN failure. It can also include HVAC failures, power outages, or hardware failures on critical, but not redundant, systems. Anything that causes a significant and protracted impact to normal operations may be enough to declare a disaster situation, and require that you implement your recovery plan.

Disaster declared, now what?

In the best case disaster, you have experienced a hardware failure that will eventually be corrected by the vendor. But while systems are down, your phone is ringing off the hook, you’re getting pinged on email and IM, and someone is probably sticking their head in your cube every 30 seconds asking if it’ fixed yet. In the worse type of disasters, you and your colleagues are probably more worried about your family and your own property more so than the company’s, and that’s assuming all your team even made it into the office. Hurricanes, blizzards, and other region impacting events can leave you with only a skeleton crew, and most of them are going to be worried about more than just how to get the website back online and email working. That’s why you want to work the plan.

By the numbers

Think back to how this article opened. When failure is not an option and there are countless distractions going on, you want people to have something to anchor themselves with, and to keep the need for creative thinking to a minimum. You also need to make sure that things are done in a certain order, and that nothing is missed, because most things have dependencies. A plan is the guide that your team will use to enable them to focus on specific and discrete tasks, without having to make it up as they go along. Make use of checklist; I mean actual paper documents on clipboards with check marks that each step is complete, so that;

a)     If something distracts you, it is easy to pick up where you left off without missing anything,

b)     You can hand off to someone else and they know exactly where to start

c)     Someone can audit that each step was done.

Paper checklists also have the distinct advantage of not relying on technology. I once saw an organization who kept all their DR procedures online; which looked great until they couldn’t get to them while the datacenter was down!

It’s a journey, not a destination

Disaster recovery planning is an ongoing process. Plans must be tested and revised as the company grows, new systems are brought into the environment, and old systems are deprecated. Real disasters don’t happen on schedule, so training must be thorough and testing must be performed to ensure that whoever is on the clock can handle the early steps of the process until more people can get online. Staffing changes will mean that this must happen frequently, and repeatedly. It’s just a part of the overall process, so accept it. And make sure that at least two people know how to perform any part of the disaster recovery plan since you have no way to know in advance whether everyone will be able to make it into the office when a disaster strikes. Redundancy of equipment is no more important that redundancy of skillsets, and a single point of failure could be the one guy who can’t get into the office because the roads are closed.

This article was written by Casper Manes on behalf of IT Channel Insight, a site for MSPs and Channel partners where you can find other related articles on how to setup a disaster recovery plan.

Whenever someone does research on the best methods to secure a company’s network, they are sure to come across articles recommending network scanners. But what value do network scanners really provide any organization?

Network scanners generally provide two distinct important functionalities – information gathering on the network they’re scanning and information on any security issues found on that network.

Information on the network

Administrators need to keep up with the constant changes made to the network. Some might see change management as unnecessary, but this is an essential part of the process to keep a network in excellent shape. There are various reasons why administrators would want to know what software and hardware is running on their network, but the main reasons are security and the need to make sure that the changes administrators make will cause conflicts within the existent network infrastructure. When new software is installed, or updates are made to the existing installation through patching, certain configurations can make the system unusable (blue screens, for example) or unstable. To avoid this from happening, the administrator should keep a test environment which mirrors the network where these changes will be made before they’re pushed onto the live server. If users install new software on their systems without notifying the administrator, the test environments will not match the current network and therefore any pre-deployment tests will be inconclusive and not a true reflection of the current status.

Some hardware can pose a security risk to the network. It is imperative that administrators are immediately notified when a new device is connected to the network so that they can determine if there is a real risk to the company. The company’s security policy might specify that the administrator must be notified before any new hardware is connected to the network but that alone does not guarantee employee compliance. A network scanner, however, can periodically monitor the network for changes and notify the administrator as these happen.

Security issues on the network

A network scanner will also look for a number of security issues on the network it is scanning.

These generally include:

• Vulnerabilities
• Missing patches
• Unwanted open ports

New vulnerabilities affecting the network can arise on a daily basis, often due to changes in configurations, new exploits being discovered, and because of new software being installed on the network. For these reasons alone, an administrator needs a network scanner that can monitor the network for any vulnerability on a regular basis.

Next on the list is patch management.  Vendors continuously fix security issues in their software and then, release patches for the end user to install. Keeping track manually of all patches released can be a daunting task, but a network scanner helps the administrator to stay on top of the problem and apply any patches that are required.

Finally there are applications that communicate through the internet, such as web servers’ open ports for others to connect to. Every open port is a potential security risk because malicious persons will try to find exploits in these connections. It is highly recommended ports that are not in use are closed immediately. An administrator should be informed as soon as a new port is opened on a network machine. This usually happens when an employee may have installed a new application or due to a malware infection. Since the network administrator cannot be everywhere or see everything happening on the network all the time, a network scanner is an essential tool.

A network scanner is a very useful tool for administrator, making his life a lot easier. Having a ‘virtual consultant’ is a much better option that having to check each and every machine manually.

Companies that use network scanners will save time and money, while administrators can focus on more important issues that require manual intervention. Why add more work when tasks can be automated using a network scanner?

This guest post was provided by Emmanuel Carabott on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. Read more on the importance of using a network scanner.

All product and company names herein may be trademarks of their respective owners.

Here’s the punch line: there really isn’t a difference. UTM and NGF are two marketing terms that have been developed to put a label on the advance of products designed to provide various protective capabilities. The two terms do represent a somewhat different point of view; let me explain.

UTM is the representation of products that began to combine previously-separate capabilities like anti-virus, anti-spam, web filtering, and so on. This was an answer to the fragmentation of different discrete products, each with its own small task.

NGF is the representation of firewall manufacturers who began to realize that they needed to incorporate many other types of threat-prevention capabilities into their firewalls, such as (you guessed it), anti-virus, anti-spam, web filtering, and so on.

UTM and NGF were different a few years ago, but as product makers from both ends filled in functionality, they met in a common middle where there’s no longer any practical difference.

• sidebar from an upcoming book. Copyright (C) 2012 someone.

Not just hypothetical ideas, but real: spam, malware, botnets, hackers, and organized crime. They want to own your systems, steal your data, and use your systems to attack tomorrow’s victims.

A generation ago, firewalls were enough for this. Today, alone, they hardly make a difference. Instead, a plethora of defenses are needed to repel the variety of attacks that bombarding every corporate network more rapid than the frenzied spattering of a Geiger counter next to a Chernobyl souvenir.

• excerpt from an upcoming book (someone owns the copyright, but I can’t tell you who)

When news of the dropbox scandal was made public, I was not surprised. The promise, “only a customer has access to their own data”, evaporated. Not that it was ever a promise that could ever be kept.

Recommendation: if you insist on storing your data on someone else’s system, encrypt it locally and store the encrypted data on the other system. That is the only way to truly guarantee that no one else can see your data.

Reference:

http://techcrunch.com/2011/06/20/dropbox-security-bug-made-passwords-optional-for-four-hours/

• Tier I – Basic Reliability Power and cooling distribution are in a single path. There may or may not be a raised floor, UPS, or generator. All maintenance requires downtime.
• Tier II – Redundant Components Power is in a single path; there may be redundant components for cooling. Includes raised floor, UPS, and generator. Most maintenance requires downtime.
• Tier III – Concurrently Maintainable Includes multiple power and cooling paths, but with only one path active. Includes sufficient capacity to carry power and cooling load on one path while performing maintenance on the other path. Includes raised floor, UPS, and generator.
• Tier IV – Fault Tolerant Includes multiple active power and cooling distribution paths. Includes redundant components, including UPS and generator. Includes raised floor.

In the early 1990s, client-server computing was all the rage. But it sucked, because networks were too slow and because updating client software was unreliable. Then the web happened, and soon, applications were we written for web browsers. It was a great time, for a while.

Client server is back, and it’s now – arguably – the dominant computing model today.

I’m talking about smartphones (iPhone/iPad, Android, Blackberry, etc) with their app stores.

Smartphones are outselling laptops. And while web surfing is popular among smartphone users, app stores is where it’s at.

Smartphone apps are the new client server model.  The protocols are better (POX – plain old XML) and more efficient, HTTPS for security, and bandwidth is better. The entire mechanism for updating smartphone apps is reliable, semi-automatic, bandwidth friendly, and easy to use.

I’m not knocking web browsers, really. They are great and getting better. But the differences between them is making the development of web applications that work across all of the web platforms and versions increasingly difficult.  The web is great for lightweight application interaction, but it’s difficult to get it right in complex applications.  Making web apps work across the popular browsers, versions, and OSs is not unlike the unenviable job Microsoft has of making Windows work on everyone’s Intel-based system. In the early days of the web, you wrote HTML and it worked everywhere. Not so any more. The bloom is off the rose.

So, what about app stores for laptops / desktops?  Since app stores are accepted by smartphone users, it makes sense that we’ll see them on laptop and desktop operating systems (Windows, Mac, Linux). If you use OSX (Mac), it’s already here. Microsoft is late to the party. Again.

I believe we will see a resurgence of client-server computing in the form of app stores for all major computing platforms, and that serious business applications that were previously web based will be app-based. Just like in the old days, only better.

As a software developer, you have a lot to worry about when writing and testing your code. But if you faithfully use secure coding guidelines from the Open Web Application Security Project (OWASP), test your code with security tools, and conduct peer code reviews, then your application will be secure, giving you worry-free sleep at night.

Wrong.

OK, sorry about that. I put that trap there for you, but I didn’t really expect you to step into it. I want to help you expand your thinking about application security.

Read rest of article here (redirects to softwaremag.com)

Organizations that perform risk management are generally aware of the laws, regulations, and standards they are required to follow. For instance, U.S. based banks, brokerages, and insurance companies are required to comply with GLBA (the Gramm Leach Bliley Act), and organizations that store, process, or transmit credit card numbers are required to comply with PCI-DSS (Payment Card Industry Data Security Standard).

GLBA, PCI-DSS, and other regulations often state in specific terms what controls are required in an organization’s IT systems. This brings to light the matter of compliance risk. Sometimes, the risk associated with a specific control (or lack of a control) may be rated as a low risk, either because the probability of a risk event is low, or because the impact of the event is low. However, if a given law, regulation, or standard requires that the control be enacted anyway, then the organization must consider the compliance risk. The risk of non-compliance may result in fines or other sanctions against the organization, which may (or may not) have consequences greater than the actual risk.

The end result of this is that organizations often implement specific security controls because they are required by laws, regulations, or standards – not because their risk analysis would otherwise compel them to.

Excerpt from CISA All-In-One Study Guide, second edition