IT Security and Compliance Thought Leadership

Systematization of a Service By Richard D. Zuleg

2012-01-03T16:15:00.003-05:00

Sometimes we are faced with the taking on a new or existing project or service. This process is usually riddled with a number of problems. The first problem you may encounter is the scattered data problem. Critical bits of data can be found on the company intranet, stored on a file server, embedded in a script, or in someone’s memory. This data could be contact information, user names and passwords to systems, instructions on how to perform a task or descriptions of what a particular service is intended to be. Services often involve repetitive tasks such as doing some analysis and then creating the same email, or document over and over with slight variations. So your job is to understand what is involved and track down all of this data, get it organized, and identify the tasks involved to complete the job.

The first step toward getting your new project under control is to start collecting and organizing the data. Look for certain types of data that can be extracted and placed in a central location. The goal is to abstract as much data as possible, for example if you have a separate service document for each client try to identify common procedures and data elements. Contact information for example should be stored in a central database and documents should reference this. Once the data has a defined structure you need to define a central location for this data. A database is a usually an ideal central location for data.

Once you have decided how the data will be organized and stored you can start to look at your procedures. The goal is to find similarities between tasks and streamline the tasks as much as possible. Make tasks repeatable, cut unnecessary steps, and make sure the tasks produce the same results each time. This is where we can start to build in quality assurance. The key is to think of a long term scalable solution and define a repeatable process.

Once data is properly organized and centralized, and the procedures have been streamlined into a repeatable process with quality checks in place we can move into the final phase. At this stage the supporting infrastructure will be in place and the data will be correctly organized and referenced by our procedures. It will now be a simple matter to automate the procedures. You have now defined your data structures and written your procedures so that the process is ready to be accomplished by a machine. The machine produces and packages the product and then the product will be reviewed by a human for the final quality check and then the package is delivered to the end consumer.

To review, the steps for systemization of a service are:

Identify data that can be abstracted
Identify, streamline, and document the process
Build supporting infrastructure
Automate the process

The key is to think of long term solutions.

Looking forward to 2012 By Brad C. Johnson

2011-12-19T18:35:00.006-05:00

To all of our readers of the SystemExperts Blog: thank you for taking time out of your busy schedules and lives to review and comment on the material that we prepare for you.

We hope that 2012 brings you all a healthy, rewarding and prosperous year. Despite the continued hardships of the economy and events around the world that impact our daily lives, we see a lot of people and organizations that continue to focus on the fundamentals that help us all do the best that we can: due diligence, professionalism, and respect.

Let's keep that going in 2012!

Back to the Future: Layered Security By Brad C. Johnson

2011-11-18T09:44:00.012-05:00

In December of 2010 I posted a "Looking forward to 2011" entry that included the following simple advice: "One thing that we have learned in the last few years is that often times, it's the simple and straightforward actions that make the most sense." That is a theme that has been consistently used in this blog because it just turns out to be true. Albert Einstein once said: "Make things as simple as possible, but not simpler. "

Related to that is this advice: do not rely on just one method of securing a resource, no matter how dynamic, exhaustive, or impressive it is. We have been a consistent supporter of this equally tried and true "Belt and Suspenders" approach to everything security. Using simple layers of security is often more dependable than expensive or complex products or strategies. Just this last week, the following news was in the headlines:

"The NCAA mistakenly left its internal SharePoint site unprotected, allowing fans, media … to have complete access to its most sensitive economic information. The leak involves years of accounting information, slideshows and much more."

How is this possible? Probably because they assumed that since this data was on the "inside" (an assumption that used to be rampant throughout the industry that essentially makes no sense anymore) that the normal or default protections would be enough.

There are a number of "Belt and Suspender" tactics that probably would have prevented this exposure from happening. None of them sophisticated or complex; yet as a collection of protection layers they would have provided an environment that would have prevented the exposure, even if one or more of them had failed.

Internet facing firewall: have rules that are just as strict about what goes out as you have for what comes in: don’t allow file share protocols outbound
Monitoring: similar to the firewall, be just as concerned about traffic that is leaving the network as what is coming in: detect file share requests travelling outbound
Intrusion detection: notice that external IP addresses are accessing internal resources
Authentication: require users to provide credentials to use SharePoint services
Authorization: define acceptable users or groups that can access the SharePoint services

None of the above actions are hard to implement or require unique security infrastructure or expertise. Each one of them is providing a certain type of security awareness or protection that is related to but different than the others. No single one provides ultimate protection of the internal resource but as a whole, they represent a layered approach to protecting the asset; even if one or more of them are, for whatever reason, not working.

So, here we are ending 2011 just where we started the year: focusing on fundamentals; preaching about straightforward and layered security philosophies.

Extending your Shields into the Cloud By Jason Reed

2011-09-06T08:40:00.001-04:00

Business IT departments are always looking for advantages and ways to save money. Outsourcing processes to other companies that have a core-competency in highly specialized or costly functions allows business to focus on their products and services, while saving money. Common examples include off-shoring code development or replacing costly datacenter, hardware, and sometimes software costs with cloud services.

Naturally, the IT environment and its resources still need to be protected. This means that the perimeter is extended to cover its computing resources wherever they may be. While there is still a core perimeter, the contents of that perimeter are changing. Where before we saw all computing under one roof, now we are seeing the extension of the perimeter to other, hopefully, trusted partners.

Companies and consumers are using Software as a Service providers more and more to instantly fill a need in the organization. Services like Gmail, Expensify, ManyMoon, Gravity, and too many more to mention allow businesses to rapidly and inexpensively consume critical business services. However, because theses SaaS deployed services are often beyond the control of the organization, they weaken the ability of the business to rely on the security of these functions. In many cases, we have seen where so much of the infrastructure used by a business has been put in the cloud, that the only reason for perimeter security is to protect the desktops used by the employees at the site.

Infrastructure as a Service (IaaS) allows businesses more control over their resources. While SaaS and Platform as a Service (PaaS) services leave the business with limited control, IaaS is still seen as an extension of the businesses computing infrastructure. There is a growing market for products that can “extend the shields” around these remote outcropping of computing resources. These systems, real or virtual, are maintained by the business and are often classified the same way as a remote datacenter or office location. With the ability to deploy private clouds at many IaaS providers, there is little difference between IaaS and a remote co-location facility. In these cases, interconnection between the two sites is the only item not owned by the business.

Unfortunately, many companies have not yet gotten their head around cloud computing and what it means to their business. The cloud is just like any other resource, inside or outside of the perimeter. The Cloud Security Alliance has published in invaluable paper on cloud security entitled, "Security Guidance for Critical Areas of Focus in Cloud Computing V2.1". In it is a section titled, "An Editorial Note on Risk: Deciding What, When, and How to Move to the Cloud" that every IT manager or security officer should read about moving to the cloud. That covers the resources in the cloud. What is left is how to integrate the resources at the business with the resources in the cloud. Essentially for IT Security practitioners, this forces the question of how to extend perimeter security to a different computing structure often outside of your control.

Business are moving slowly, absorbing the cloud options, and deploying non-essential functions to the cloud initially. As many see that they can extend their functions to IasS providers, or release control to PaaS or SaaS providers, they are making their way to the cloud. Of course, we will not see all companies releasing control of their infrastructure to others any time soon, but instead a slow migration as more controls because exposed to the users. For now, I foresee many more private and hybrid cloud services. The Cloud Security Alliance lists a hybrid cloud with the following definition:

"Hybrid Cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds)."

"There is always a trade off between security and accessibility". That is a common phase we hear in information security. We don’t employ moats or towering castle walls as much anymore to protect our interests, but each in its day provided a level of protection against outsiders. Each also provided challenges to access the protected resources by legitimate users. (I don’t know if you have ever had to raise or lower a drawbridge, but that is hard work). The benefits of a well-defined perimeter are that we know what we want to protect and what to expose.

Today, we are increasingly exposing more and more functions, while still trying to protect them as much as possible. This duality creates challenges whose solutions are bountiful, but are often complex to maintain. Companies want the best of both worlds, maximum protection, and maximum access. The trick is finding the right balance to allow the business to actually stay in business.

Securing Dropbox (and other cloud syncing services) By Keith Royster

2011-07-01T16:47:00.009-04:00

As the number of computers, laptops, and mobile devices we use grows, services that sync our important files between them grow in popularity. But are these services secure enough to store our confidential files? Recent news suggest not. One of the more popular file-syncing services, Dropbox.com, has experienced recent and significant security issues this year, including a brief lapse in their authentication system that made passwords optional for a 4-hour window. And not to pick on Dropbox - virtually all of these services carry some security trade-offs by design, including them having the keys to your encrypted files so that they can de-duplicate data to minimize storage requirements. Syncing confidential files in the cloud is not recommended without additional encryption.

All encrypted syncing solutions are not created equal

Searching the internet for "securing Dropbox" will result a myriad of blogs suggesting various ways to encrypt your cloud-synced files. What they all have in common is that they attempt to encrypt your files locally before they go into the cloud. But not all local encryption methods are best suited for cloud-synchronization. SystemExperts spent some time trying many of the suggestions found online, but experienced the following issues with most of them:

Tools that create encrypted volumes within the Dropbox folder create a single large file that must be synchronized every time a single file within it changes, making it very slow. And often times the size of the these volumes cannot grow, so a single large file must be created from the start. These problems were common to tools such as TrueCrypt (cross-platform) and encrypted disk images such as .dmg and .sparseimage files (both built-in for OS X only).

OS X has a disk image format called "sparsebundle" that it created precisely for syncing files to its Time Machine backup service. It solves the problem of syncing entire volumes by dividing it up into smaller "bands". But this is not a cross-platform solution. Additionally, testing indicated that Dropbox had trouble detecting changes to the "bands" in real-time, and had trouble synchronizing them if the volume was mounted by multiple systems.

Encrypting individual files makes for faster syncing, but can be tedious if it must be done manually with tools such as zip-archiving tools.

EncFS to the rescue

SystemExperts found EncFS (or Encrypted File System)solutions best suited for the task. EncFS uses AES-256 encryption, is cross platform (Windows, Linux, and OS X - sorry, no mobile yet), and it encrypts individual files on the fly as they are placed into the mounted EncFS volume. As an added bonus, EncFS provides some protection for lost or stolen laptops. EncFS mounts the encrypted files on your file system and displays them decrypted at the mount point as a new drive or volume, so as soon as the system is powered off or the user logs out, the mount point is lost and the decrypted files are no longer available.

However, there are some caveats to EncFS:

The only Windows solution we found is a commercial application called http://boxcryptor.com/ which starts at $20 for commercial use, although it does offer a free version with some limitations
Although free, the OS X and Linux solutions are more technically challenging to install
Although the file contents are encrypted, anyone with access to the file system can see how many files and folders exist, their permissions, their approximate sizes, and their last accessed and modified timestamps.

Example usage of EncFS

In our test setup, we synchronized files across multiple OS X systems. Following these installation steps for OS X , we created a folder within Dropbox for our encrypted EncS files, and an EncFS mount point outside of our Dropbox folder. (Tip: On OS X and Linux, name the folder within Dropbox using a preceding . (dot) to make it invisible. This way you aren't tempted to place unencrypted files within the encrypted EncFS folder by accident.) We named our new EncFS volume "eDropbox", which showed up on our Mac as a new attached drive. After repeating the setup process on two additional systems, we began placing files within this new eDropbox drive. Files were immediately and transparently encrypted to the EncFS folder within our Dropbox folder, and then synchronized to our other systems, making the unencrypted file immediately available on all of the respective mounted eDropbox volumes. But anyone accessing our Dropbox account in the cloud (including the operators of the service itself) will now only find AES-256 encrypted files there.

Please let us know how EncFS works for you, if you find other solutions that work better, or how your company is addressing secure file synchronization.

An Artist and his tools By Jason Rhykerd

2011-06-23T15:19:00.004-04:00

I ask you, what does a security analyst have in common with Picasso, Shakespeare, and Mozart? You are probably asking yourself how one could begin to make such a connection. The connection, they are all artists with different mediums. Picasso had his paints; Shakespeare had the stage; Mozart his violin and piano; and the security tester his experience and knowledge.

While Science plays a critical role in the world of Information Security, it is strongly complemented by Art. Merriam-Webster defines Art multiple ways; I personally like the following two meanings:

1. A skill acquired by experience, study, or observation
2. The conscious use of skill and creative imagination especially in the production of aesthetic objects;

For this posting I ask you to think of findings from a penetration test or a web application test as aesthetic objects. While science helped us to discover the [potentially] vulnerable variable, or those open ports, it’s art that determines the real risk and validity of the finding, as well as uncovering their hidden meanings.

Take the following very simple example. We have a web application whose URL is www.mybadapplication.com. Using an automated web scanner (i.e. Science), we scan the web application. The scanner returns us a list of parameters that are used within the application. One of the variables is “admin” and is found as a get parameter (www.mybadapplication.com/?admin=false). To the automated scanner this is just another variable, to the security analyst (or artist) this variable is much more interesting. An artist is going to immediately change false to true and evaluate the response, whereas the automated scanner only lists the variable and flags no risk.

Let’s now assume that our scanner returned a finding of SQL injection. Almost every set of tools I have worked with rates SQL injection as a Critical or High finding. I don’t necessarily disagree with this rating, SQL injection can lead to serious compromise. But is the finding valid? Many of the tools out there go to great lengths to validate findings, but their automated actions are far from perfect. Once again our artist will work to determine whether this finding is a false positive, and if not, he will determine what risk it presents to the organization.

The interpretation of the finding, just like art, is derived from many influences. The security analyst has multiple factors to consider when determining a finding’s risk – how likely is it to be discovered, are there known exploits in the wild, what is the technical skill level to perform the exploit, or what is the impact to the organization?

If you ask two different critics to interpret the same piece of art, chances are you will get two different points of view. Similarly, the same finding at different organizations may have a different set of risk. Factors such as type of industry (Financial, Medical, Government, etc), impact to organization, and even public relations play a significant role in our interpretations.

It is a true artist who is conscious of this, can think out of-the-box, and can be creative to provide their client actionable and value-add results.

Can the science exist without the artist? Yes, but I have seen many automated reports shoved in front of developers only to be thrown away by the developer because it was filled with false positives and meaningless data. I believe the two ideas complement each other and neither one is not as powerful without the other.

Thinking about Onions By Jason Reed

2011-04-13T15:28:00.005-04:00

Another security firm hacked. That’s the story coming out of Barracuda Networks where attackers successfully exploited a SQL injection bug in a PHP page and were able to dump the contents of the MySQL server supporting the content on the external site.

Exposed were customer names, logins, email addresses and phone numbers, Barracuda Network employee’s credentials, and credentials of the MySQL database itself.

The official word from Barracuda is that a web application firewall in front of the web app was accidentally placed in passive monitoring mode during a “maintenance period” and was not reactivated. The SQL injection allowed the attackers to gain access to at least 5 databases and their associated tables. Some of the table names shown in the release by the hackers: CHAT_ADMIN, MySQL’s USER, BUNIVERSITY_USERS, CMS_LOGINS, and DEAL_REG.

This would seem to be the year of security giants falling to attacks. With RSA’s well-publicized issues already, we stop and wonder that if these companies, who hopefully think about security often, can fall, what chance does the common .Com have?

Taking a look at the Barracuda attack helps us all learn lessons about the way we should do business on the Net. Let’s hit some of the highlights.

First, the WAF was disabled for maintenance, which left the web app behind it susceptible. What this means to me is that the application could of always had this issue, but the WAF masked it from the outside. Many will say to “let the firewall do its job”.

However, I think of onions.

We have all heard of defense-in-depth. The idea is that each service should protect itself in case of a failure in the next layer up. In Barracuda’s case, the PHP page was susceptible to SQL injection, which was blocked by the WAF up until Friday. The problem was, the PHP page should have protected itself by escaping the input, using parameterized queries, and applying a white-list to the input instead of relying on the WAF for all of these functions.

Security-based code reviews should be a part of everyone’s software development practices. Looking for dynamic SQL statements in code is easy. Looking for more complex vulnerabilities from user input takes a code review. As we often tell our customers, you could be one click away from being compromised if you don’t make security part of each layer.

The next issue was a violation of least privilege. This basic security tenant states that a principle (in this case a web application) should have the least amount of privilege needed to perform its functions. Some may say that a single application credential having access to all the databases simplifies development and deployment reducing the possibility of errors.

I, however, again think of onions.

From the hacker’s release, it is clear that the user ID used by the application had access to other databases, including the system table. Instead of using a powerful user ID for the application, the database should be configured to only allow access to the data that it requires for servicing its requests. This means, performing an analysis of the data contained in the system and what is needed for each application. Requiring multiple user IDs for access is a good way of segmenting access to the data. The attacker might have to break a couple of layers to get at anything important. At a minimum, this lengthens the time of the attack and hopefully it can be shutdown before an exploit is found.

Last, the failure of the WAF to block traffic exposed the issue with PHP. We always encourage our customers to test the periodic failure of their protections to see if the next layer down is secure. Test your systems without the benefits of your WAFs or Network Firewalls and see where your weaknesses truly lie. Take the time, at least annually, to discover if your onion has just one layer.

Bon Appétit.

Data Loss Prevention: Getting Started By Brad C. Johnson

2011-04-05T11:52:00.014-04:00

The term DLP, or Data Loss Prevention, tends to conjure up somewhat polarizing reactions such as “That’s the most important thing in our IT environment!” or “What is that?” The reality is, both reactions are perfectly reasonable.

The minute you start talking about Data Loss Prevention, or Data Leak Prevention/Protection, or, Information Loss/Leakage Prevention/Protection, or Content Monitoring or whatever, and finally get past the acronym du jour and realize it is a conversation about monitoring confidential data, everybody is interested and concerned about the topic.

Some organizations use the DLP title and create specific initiatives or employee roles based around the topic. Other organizations consider it a by-product of the other security or IT infrastructure they already have in place. I’m going to put a stake in the ground and say, it needs to be both.

The reason you need to explicitly consider the DLP topic is that normal and even formal security frameworks don’t usually provide good coverage of all of the DLP issues. Why is that?

At the heart of DLP is that most IT environments don’t include an explicit requirement to actually monitor data payloads in many normal day to day tasks and operations. We monitor users, we monitor intrusion attempts, we monitor changes to our Web site, we monitor unexpected protocol attempts on our firewalls, but we often have no idea all of the places our confidential data resides or how it got there.

According to studies on data loss, most companies have lost data on laptops and USB drives, Personal Identifying Information (PII) is often found on expected drives or systems, and an unexpected number of simple unencrypted emails have sensitive information in them. [The Open Security Foundation has catalogued a Data Loss Data Base and is focused on giving news about the details of data loss incidents: http://datalossdb.org/statistics]

The reason this happens is that most data loss is not from malicious attacks (although they tend to be the cases more publicized and scrutinized), but instead can be attributed to employee actions such as:

not following documented policies
storing files with sensitive information on public or lightly secured storage devices
using inherently insecure but popular technologies like social networking applications or instant messaging
putting sensitive information on mobile devices like laptops or Smartphones

In other words, data loss often happens in the course of doing normal work and trying to do your job.

Now that I have planted the seed on why you need to care about DLP, stay tuned for more detailed and focused entries on this important topic.

How do you detect an APT?By Phil Cox

2011-04-04T07:58:00.001-04:00

This is the question of the day, and one that I have done a lot of thinking about. I have come up with the following straightforward, yet non-trivial to implement process that I feel would best allow an organization to detect an APT occurring within their IT environment.

While the list is short, it is non-trivial to execute. It would take a decent amount of resources and time. I am convinced, that if “completeness” is not the rule, then the goal of detecting APT is unrealistic. You’d be better saving time and effort and relying on luck. I am GUESSING (absolutely no empirical evidence to support) that even following this process you are only 60% likely to detect an APT. Which is significantly better than my other gut feeling that you are < 10% likely without it.

I base some of this on the OCTAVE methodology (from CMU) for Risk Management, as I think it can get people through step 3 with modification.

Identify and document the top 5 high target business processes
a. Note I say High target, not critical. While they may coincide, I won’t make the leap that they are guaranteed to be the same. If we are looking at APT, we want to look at what it most likely going to be the target
Identify all operational and business workflows for the top 5
a. This would include network traffic/flows
b. Rank each in terms of effect if breached
Identify all information assets that are included in or used by those high target processes
Identify what an anomaly would look like if a 2.a occurred
Instrument SIEM to identify those anomalies
Perform a complete investigation, through remediation, of any alert from 5

RSA Cyber Attack By Brad C. Johnson

2011-03-18T11:00:00.002-04:00

The recent news that EMC’s RSA infrastructure was the target of an (apparently successful) Advanced Persistent Threat (APT) cyber attack is serious news in the IT and security world. A lot more information will need to come from RSA about the details of the actual compromise and what that means for RSA customers and the systems we try and protect using RSA products. Here is a link to an RSA open letter about the situation: http://www.rsa.com/node.aspx?id=3872. EMC’s SEC filing of the situation is located here: http://www.emc.com/about/investor-relations/sec-filings.htm - Refer to “Report of unscheduled material events or corporate event” dated 03/17/11.

In the meantime, there are some things that we all can do as we wait for more details:

Notify all staff using RSA tokens of the situation and ensure they are following corporate password quality standards
Ensure that staff are following RSA specified best practices (e.g., PIN management, system hardening, token distribution)
Monitor logs for increased authentication failures, social engineering attacks, or phishing attacks
Tightly monitor RSA responses, recommendations, and announcements
Refer to the RSA SEC filing under the section “SCOL Note Title: Required Actions for SecurID Installations” for detailed RSA recommendations

Despite the fact that this is indeed a serious situation and leads to the direct possibility that one may need to consider using different technology, until we get more information it’s probably more prudent to sit tight with the technology you are already have in place and ensure the above recommendations are being followed.

Having said that, you should set some well-defined checkpoints within your organization in the near future to either agree or disagree on how to move forward with the use of RSA technology and their response to the current situation.

SmartPhones: embrace them to secure them! By Brad C. Johnson

2011-02-23T17:43:00.002-05:00

People who own SmartPhones live by them. People who don’t, soon will!
SmartPhone usage and the applications we run on them are only going to increase in popularity and for many people, they are becoming essential business devices.

The first step in helping these tools to be secure is to embrace their existence and define policies, procedures, and mechanisms to configure, use, and manage them. What data can and cannot be stored on the phone? How will email be handled? What applications will be allowed on the phone? Most of these policies will deal with data sensitivity, data handling, and risk management.

The second step is to decide which SmartPhones will be approved. You should choose phones based on the existence of functionality (either directly on them as native functionality or as a third-party application) that will support your requirements and high level security policies. Can you encrypt the data on the phone? Can you perform a remote wipe of the phone if it is lost or stolen? Can you configure it and key applications with passwords or other secure tokens? Most of these issues will deal with security policies, operational management, and device management.

The third step is to define the tools and protocols that each person will use that minimize the risk of exposing confidential data or inappropriate access to the phone itself. How will the phone connect to the network? What kind of virus or malware protection is used? How is the device secured? These topics will force you to deal with access control, information security, and incident management.

If all of this sounds like a lot of work, it can be but it really is an acknowledgement that SmartPhones are the new laptop and you’ll have to put the same amount of effort, controls, and management in place to deal with them as you did with your laptop infrastructure.

Companies that are doing poorly in this space haven’t embraced the technology as a peer of the laptop or desktop. Companies that are doing well, have expanded their security policies and procedures to deal with the unique capabilities and risks that come with the SmartPhone.

My advice? Embrace them as the next generation of mobile computing and secure them to create real business opportunities and advantages!

Cloud Security: the next new/old worry! By Brad C. Johnson

2011-01-18T14:48:00.003-05:00

From a security point of view, every time we come to grips with new technology it seems we have to reinvent our understanding of what makes something secure or not. In reality, however, we already know most of the things we are going to have to do, we just need to learn the nuances and language of the new hardware or software and apply them.

Remember: When Java was going to make everything safe because of the sandbox? Websites that were apparently protected from hackers because they were certified by some organization or standard? Desktops that must be secure because they had the latest virus and malware detection? OSX didn’t have any exploits?

The fact is, as we all know, security is not a state but a process: an ongoing process of continually making things a little bit better than they were before. Authentication. Authorization. Auditing. Policies and procedures. Periodic reviews and assessments. All of the key ingredients are already well understood. Now we need to apply them all over again to this new environment.

Moving to the Cloud – and remember there are a number of different Cloud initiatives and deployments – brings with it the same security concerns as before. Whether you are moving to Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) you are going to need to think about your security stance and how to either protect or detect when your systems or services are being inappropriately accessed. How does your Cloud provider account for regulatory compliance? Exactly where (physical location) is your data residing? How do you know that your data is appropriately segregated from other company’s data?

Here are a few short articles written by SystemExperts that can help jump-start your understanding of various security issues within the Cloud. In addition, go to your favorite search engine and simply put in “Cloud Security” and take a look at the wealth of articles that exist extolling on the various issues you need to come to grips with. A little bit of research and analysis will quickly reveal a number of concerns you need to plan for.

Don’t be afraid, you have done this many times before and it won’t be the last.

Looking forward to 2011 By Brad C. Johnson

2010-12-15T11:34:00.002-05:00

To all of our readers of the SystemExperts Blog: thank you for taking time out of your busy schedules and lives to review and comment on the material that we prepare for you. We appreciate your readership.

One thing that we have learned in the last few years is that often times, it's the simple and straightforward actions that make the most sense. We had several posts this year specifically dedicated to this from War Dialing to Event Management to Auto Updates. Not only does the direct approach tend to be the most manageable it also tends to be the less expensive option: actions that can be more readily understood tend to have lower on-going costs. Let's try and remember that instead of getting caught up in elaborate, expensive, or technology-of-the-moment solutions.

May you have a safe, healthy, and rewarding 2011!

War Dialing: Old school technology yet surprisingly contemporary application By Brad C. Johnson

2010-11-09T15:55:00.001-05:00

War Dialing is an activity and security threat often associated with the 1980s and 1990s. Of course, the film “War Games” made this hacker activity known to practically everybody. To a large degree, the concern about people dialing into your modem based services was replaced with concerns about the next big thing the Internet, then WiFi. War Dialing testing was replaced with War Driving; the search for unsecured wireless networks.

Since then, we have moved onto Bluetooth issues and now onto 3G and 4G mobile networks as the next new communications mechanisms to worry about. But a funny thing has happened along the way; modems never went away. They remain a popular way to remotely control important services like power systems, complex printer systems, and communication subsystems to name just a few.

Why has this happened? One driving force is that the depressed economy has forced many organizations to do a lot more work with a lot fewer people. One way to make a person more effective is to allow them to manage resources remotely. Getting a phone line hooked up to a modem is a cost-effective way to get communications setup between two locations.

Another way that organizations reduce cost is to outsource their IT resources. Similarly, the way these outsource organizations make money is to have individual technicians responsible for a variety of clients and to manage those resources remotely.

Although a significant security risk, one of the great administrative advantages of a modem based access to a resource is that it bypasses all the normal network protections that might exist on a normal Internet connection, such as firewalls, routers, application filters, intrusion detection systems, and ISPs. Figuring out how to configure a communication path that can reliably work over an Internet connection, where you don’t own or manage most of the systems you traverse, can be complex and expensive. Setting up a simple modem connection, however, can be quite trivial, cheap, and easy to manage over time.

The end result is that many organizations here in the 21st century are making good practical use of simple modem based access and management of remote resources. The key to managing those resources securely is to periodically assess their security stance in much the same way one manages Internet connection points by routinely performing host based or web based vulnerability assessments.

The way to check those modem based services is with the tried and true, simple yet effective approach called War Dialing. Have you checked your modem based systems lately?

You Just Never KnowBy Jonathan Gossels

2010-10-14T11:39:00.004-04:00

In business school, Professor Eric Von Hippel taught us to look to high need and lead users as a source of innovation. Reflecting back on the services that SystemExperts offers, he was exactly right.

Our Security Blanket service was born out of the need of a major financial institution to make sure that the web site supporting its high net worth investors was operationally secure and continuously monitored.

Our penetration testing services were born when Prodigy (yes, remember Prodigy, it was a long time ago) needed to be sure its systems and infrastructure could withstand hacker attacks.

This year, it is Security Information and Event Monitoring (SIEM). For years we’ve been advising clients that they need to instrument systems and applications to detect security events and regularly review system and security logs. Guess what? Too many IT organizations are understaffed and overworked. Most organizations don’t have the cycles to consistently perform this most basic of security hygiene.

2010 is notable as the year that several of our clients turned to us and said, "Can you just do it for us?" Since we’ve advised clients in setting up and operating Security Information and Event Monitoring systems for years, we said, "Of course."

If you find yourself in this same situation, you are not alone. Compliance requirements are forcing this issue.

Incident or Event Management: Keep it simple but real! By Brad C. Johnson

2010-08-31T12:08:00.006-04:00

There is probably no single topic area that is more documented and discussed than that of Incident or Event Management. In addition, there are as many tools in this space – public domain, open source, and 3rd party programs –as almost any other area for your IT environment. Yet oddly, this is one of the areas almost every organization has problems with.

In an article in the June addition of ISSA I addressed a number of important basic security areas including this one (here is a copy of that article: http://www.systemexperts.com/assets/pdf/ISSA0710-Johnson-SecurityBasics.pdf). Let’s revisit some of the key issues in this area of incident management.

All too often, people wait until after they have had an incident to figure out a plan for reacting to one. The normal outcome is that they are woefully unprepared for the first incident, gather the wrong information, do not know who to contact or who is responsible for managing the situation, and taint the evidence because of the lack of well-documented procedures. While it’s good to be prepared for any incident, it’s usually pretty easy to at least agree on the top 10 events that you know your company should be prepared to handle.

Interestingly, in most cases, the basic instructions of what each person should do will fit on one page. For managing the event you need to clearly state the chain of command for making decisions, define a policy for how your organization will respond, learn, and improve your procedures for future incidents, and make sure you have spoken with appropriate authorities to understand what evidence needs to be collected.

The first step is to develop a (small) list of real-case scenarios that you need to be prepared to handle, for example:

• A virus somehow enters the internal network and is infecting systems
• The corporate website has been defaced
• An unauthorized mobile device has connected to the corporate internal wireless infrastructure

For each of these events, you would want to document the exact steps that each person involved would perform and identify specific people (and their backups) that would execute the work. Once you have defined these things you want to try them out to work out the kinks. Trust me, there will be problems.

Our experience has shown that you will find that there are important steps that have not been documented, that not all of the appropriate people have been identified that need to be involved, and that you have invalid assumptions built into your understanding of what it will take to be fully recovered. It normally takes a number of iterations through the process to fine tune the game plan for a quick recovery.

Let’s get going on this! Document your top 5 incidents, describe who should handle the incident and what they should do, and then try running through those scenarios to work out the fine-grain details so you are prepared to deal with them.

Auto-updates: it’s time for some transparency! By Brad C. Johnson

2010-06-16T13:19:00.002-04:00

StopBadware.org hosted a chat in February of this year talking about auto-updates to software. In particular, what to do with security updates. Here is a link to some notes about that chat session: http://blog.stopbadware.org/2010/02/10/lessons-from-the-auto-update-web-chat.

There are some very interesting issues that fall out of this debate including: Is there a difference between vulnerability fixes and straight product upgrades? What are the requirement differences for an individual user dealing with an update vs. that of an enterprise? Where is the appropriate place to offer an opt-out for an automatic update? How do users separate software licensing issues from automatic security updates?

What seems to be clear to me is that the auto-update process needs to be made much more transparent. Administrators want to know what systems, files, or other resources the update process is communicating with at all times. Right now, a lot of things can be created, modified, or deleted and you have virtually no insight into when or why those actions are taken. Any other kind of update made to a computer or network is usually very tightly managed and described in great detail so that people can be prepared for potential problems, side-effects, or impact.

Right now, many auto-update processes are simply an either/or situation: either you install it, or you don’t. That’s not enough information or options for most IT environments.

Data Anonymization for a Multinational BankBy Jonathan Gossels

2010-05-24T09:04:00.004-04:00

We just finished an intensive multi-month effort helping a premier multinational bank figure out how to eliminate production data from its development, test, and QA environments. One of the dirty secrets in our industry is that all too often real data is used in these environments without any of the controls normally associated with protecting account information, counterparty information, and firm specific intellectual property.

This general topic area is often referred to as Data Masking, but technically, data masking is simply one of many data obfuscation techniques. This particular project had some interesting challenges:

• The firm has both private banking and investment banking operations. Their data anonymization requirements varied substantially. For the investment bankers commercial off the shelf products and well known off-shore managed service providers satisfied its needs. In contrast, the private bank determined that based on local banking regulations, and its own risk appetite, that using anonymized data was insufficient because the original data might be disclosed via statistical analysis. The private bank requires the use of synthetic data, which has been created solely for development and test purposes and is not based on actual production data. To meet this need, it developed a customized solution in house.

• The firm outsources significant portions of its operation to lower cost geographies. This raises the challenge of complying with local data protection zone laws. The firm has to ensure that production data doesn’t leave its local jurisdiction while also ensuring that its off shore developers have data to work with that has internal coherence (e.g. twelve monthly net income fields actually add up to annual net income).

In the end, the complexity of the overall project was lowered by reducing the number of technologies and service providers. This reduction means that some parts of the bank have to migrate to different methodologies but the benefit is a significant reduction in support and maintenance costs. The bank can now also more quickly adapt to new anonymization requirements. Tackling data anonymization is a hard job but one that has the opportunity to protect the organization from leaking sensitive corporation information.

2010 Security Resolutions By Brad C. Johnson

2010-01-21T10:15:00.003-05:00

Many people create New Year’s resolutions to motivate themselves to improve on something. Let’s do the same thing for the security of our IT environment. My advice for security would be to keep it simple and remember that security is a process, not an end-point. Everything we do that raises our bar a little higher and makes it more difficult for bad things to happen – whether it’s malicious or unintentional – is a good thing. Here are two resolutions that you should follow to make your environment more secure.

Defense in depth: I know that’s a catchy phrase that you see in many places but it’s a great way to think about security. The opposite, to state the obvious, is a single point of failure. If you have only one way to protect a resource, any time that protection is either compromised or disabled, you are going to be vulnerable. Just like this list, I like to keep things simple. List out three, four, or five things that you care most about protecting in your environment. Do you have at least two ways (three ways?) that each of those resources is protected? If not, take the initiative to add one layer to each one.

In almost all cases, the best protection is an actual mechanism (technology) that enforces the policies you have defined. It’s good to have a policy that states how passwords will be handled, it’s better to have a mechanism that enforces it. If you can add a mechanism to raise the bar on one of those 3-5 resources you just listed, do it. If not, then at least add some type of process or policy that helps you. For example, if a Web application you have is not instrumented to log security exploits (i.e., create an alarm if somebody is injecting cross site scripting text or trying some type of command injection), then create an automated process (script) that periodically reviews the Web logs to look for those events and create an email or some type of event for somebody to follow up on. Don’t be afraid to use simple techniques that make a big difference in either preventing or detecting when things are not going well.

Controlling Network Traffic: I want more people to accept the fact that they need to be just as concerned about what goes “out” of their network as they are about what comes “in.” Almost every organization has spent a lot of time thinking about how they want their routers, gateways, or firewalls setup to filter, forward, route, or block incoming traffic. Unfortunately, most of these same organizations have not spent a lot of time thinking about how to address outgoing traffic. Often, they will allow most if not all traffic “out” to ensure they don’t introduce access issues for people inside the boundaries of these devices.

In a nutshell, most viruses, Trojans, and worms succeed because of this situation! Most of these kinds of problems depend on the ability to get around to other systems near them (because people tend to trust systems on the inside) and then to propagate themselves to other systems and networks. This often succeeds because trust levels are too high within a particular network segment and outbound traffic isn’t managed very well.

A good starting point for defining rules for your outgoing traffic is to start with the same rules you just setup for incoming traffic and adjust only for those ports, services, or protocols that are absolutely essential. Not only will this help to thwart “infections” you do incur on the inside of your perimeter, it will help to minimize unwanted traffic and save more bandwidth for production and work oriented services.

Looking forward to 2010 By Brad C. Johnson

2009-12-22T07:28:00.005-05:00

To all of our readers of the SystemExperts Blog: thank you for taking time out of your busy schedules and lives to review and comment on the material that we prepare for you.

We hope that 2010 brings you all a healthy, rewarding and prosperous year. Despite the hardships of the economy and events around the world that impact our daily lives, we see a lot of people and organizations that continue to focus on the fundamentals that help us all do the best that we can: due diligence, professionalism, and respect. Let's keep that going in 2010!

Net Neutrality By Brad C. Johnson

2009-11-17T17:00:00.007-05:00

Net neutrality, at its essence, is about deciding how much a telecommunications carrier can control content (i.e., Internet traffic) on the network. Should the carriers be allowed to block or slow content to the end user?

Internet providers want unfettered access to content for their users because they want as much potential data as possible to get to their target audience: their customers using the Internet: often, to help generate ad revenue. Users, even if they don’t know it, want unfettered access to content because they don’t like the idea of somebody deciding what they can and can’t see or how quickly they get the data.

Carriers, on the other hand, want the right to manage content because it helps them in several important areas. First, Internet traffic traverses over wildly different communication bandwidth mechanisms ranging from (yes it still exists) dial-up, to broadband cable, satellite, WIFI, and phone systems such as 3G and 4G. Carriers don’t want to use up valuable wireless bandwidth with, in their minds, unnecessary data.

Second, carriers are more in favor of a tiered service model to generate revenue. For example, if you want content being delivered at the fastest possible rate you would pay a “tier 1” price. If you can’t afford that or instant availability isn’t critical for your needs, you would pay a “tier 2” or “tier 3” price.

Third, the fact is, regardless of your feelings about carriers managing content or not, it’s getting harder and harder to provide the bandwidth that people want or need for today’s applications and the need for more bandwidth is only growing. This isn’t about censorship or control, per se, but about being efficient with how to use the telecommunications infrastructure both now and in the future as the demand for more data increases.

The bottom line is, there are a lot of interested parties in this debate and those that argue on both sides of the issue: e.g., those claiming net neutrality is a must to ensure the integrity of the data you’re looking at and yet others claiming certain amounts of controlling content (data discrimination) is not only not a problem but desirable to get network “trash” out of circulation. The result is likely to be a series of negotiations, compromises, and proposals that span geographical, political, financial, and other powerful boundaries.

Portions of this text was referenced in the following article: http://www.itbusinessedge.com/cm/blogs/bentley/net-neutrality-resolution-will-require-negotiations-compromises-and-proposals/?cs=37200

Hiring “Hackers” … Please don’t! By Brad C. Johnson

2009-10-21T09:22:00.003-04:00

There is an interesting article on the NetworkWorld web site by M. E. Kabay dealing with the recommendation of hiring “hackers” to help better secure your networked environment. For a moment, let’s just ignore that the term “hacker” is ill defined and there are all sorts of other words and phrases that are meant to clarify the issue like “Black Hat,” “White Hat,” “Gray Hat,” “Cracker,” “Ethical Hacker,” etc. For this blog let’s just agree that “hacker” is not an employee of yours and somebody who can break into computer resources.

On the one side is the idea that hiring hackers is a good thing because, even though they may have done bad things in the past, they actually know how to “do it.” That is, break into resources on a network. The theory is that too many security professionals have been ordained as security experts just because they work in a security IT job function and/or they have attained some number of technology oriented certifications. The argument is that just because you have the job title and certification, doesn’t make you actually good at hacking.

On the other side is the idea that hiring hackers is a bad thing because they can’t be trusted, well, because the reason they are called hackers is that they have done bad things without permission: e.g., break into systems they don’t own.

The primary authors on either side of the argument are professional and credible enough to see valid points on both sides. Unfortunately, all of that dialogue doesn’t change, what I believe is, the most important point – a point raised by one of the people who posted a response: restraint.

While it may be true that every security IT professional does not have the skills or expertise of a successful hacker - and let’s not forget that most hackers are actually not that successful and the vast majority of them copy the successes [aka “script kiddies”] of the few truly original and creative ones - one of the behavioral characteristics that most of them do have is that they feel constrained to do things in a certain professional and organized way to ensure the stability of their environment: that is, they have restraint over what they do. Most hackers have no restraint in what they do: they feel comfortable doing anything, at anytime, to achieve a goal no matter what consequences it has on the environment.

It can be argued that one needs to have exactly that kind of destructive freedom to replicate what a hacker might do. I agree, and the way to achieve that is to have protected and segregated (e.g., QA environment) environment where your trusted professionals can try anything they want: not from hiring hackers who may steal or corrupt sensitive information, leave systems less secure than when they found them, or who may infect tested systems with Trojan horse or denial of service software that will be used at a later time – when they are doing their hacking for yet another victim.

Hire a hacker? Please don’t!

New exploit area: Cross Site Printing (XSP) By Brad C. Johnson

2009-09-23T11:26:00.003-04:00

One of the true benefits of a networked environment is that it makes resources readily available to you regardless of where they are physically deployed. One of the true realities of a networked environment, however, is that it can be difficult to manage those resources securely. How do you make sure that only the appropriate people (authentication) with the appropriate rights (authorization) can use that resource at the appropriate times (access control) and you know who did it (auditing)?

Most organizations are aware of this management problem for their own Intranets and are painfully aware of the difficulty in deploying resources safely and securely on the Internet. One of the most prevalent types of network/Web oriented exploits – Cross Site Scripting or XSS – has expanded into a new area and is called Cross Site Printing or XSP. This topic started popping up in articles in late 2007 and early 2008 but has recently started to garner some traction.

XSP is a logical variation of XSS in that it is a Web oriented code injection technique. XSP allows you to get access to Intranet printers through a Web portal. Many network printers often listen for printing requests on a well known TCP port: port 9100. If you are "on" the same network or LAN as this printer and it has not been configured to restrict access to it (a common occurrence), you can send anything to that port. If a Web application happens to be on the same network as one of the network printers, you can construct an HTML request to send something to that printer. An article from Net Security describes this capability.

Just to point out how simple this request can be, here is an example of sending a request to a network printer using HTTP:

http://[PRINTER]:9100/FILE-REQUEST

"[PRINTER]" is the IP address or the domain name of the network you are on. This simple HTTP construct would send an HTTP GET request to the printer trying to GET the file /FILE-REQUEST.

As the Net Security article points out, that simple HTTP request would result in basic HTML header information being printed but one could instead send a POST and create a properly formatted request to the printer. This is just the start of a variety of exploits that could be constructed and sent to the device.

At a minimum, this exploit could be used to send SPAM to the printer, or possibly perform a denial of service by sending a lot of requests and tying it up. What’s probably more interesting is that today’s sophisticated printers do a lot more than just print. They scan and store pictures or images that could contain sensitive information that could be viewed or possibly modified if one could interact with the printer interface.

Unless the printer is appropriately secured, then, it would be possible to send data to be printed, possibly change the printer’s configuration, or use the other functions (e.g., FAX or access other network resources) that the printer offers.

Lessons from the Heartland Data Breach By Brad C. Johnson

2009-08-21T09:01:00.006-04:00

The Heartland Data Breach situation can teach us all a number of fundamental security lessons. The actual breach was in fact not a single event but a sustained set of intrusions starting back in 2006. In addition, the victims also included Hannaford Bros. and 7-Eleven.

Lesson #1: don’t just read the headlines, dig a little deeper.

The perpetrators prepared for these intrusions for a long time. They developed a set of malware programs and then ran a variety of third-party and public domain antivirus programs against the malware to ensure that it would not be detected by normal antiviral scanning activities.

Lesson #2: intruders are willing to expend as much effort as you do to achieve their goal.

Most of the intrusions were successful using relatively common attack techniques. To use a well-known analogy; if a robber can just open your front door because it’s not locked and you’re not home, there is no need to try to outsmart a sophisticated and monitored burglar alarm system next door. Sometimes, a determined intruder wants to get into your house; most times, a burglar just wants to get into some house – so get into the house that’s easiest to get into. On the Internet, it’s often the same thing.

Lesson #3: many intrusions are the result of finding the easiest opportunity.

Heartland had recently passed a PCI DSS assessment. As we all know, however, passing an assessment, audit, or even being deemed compliant is not an end-goal, but a point in time evaluation. IT environments are constantly changing and therefore there are always challenges in keeping your security stance stable.

Lesson #4: passing an audit probably means you’re safer, but it doesn’t mean you’re safe.

Everybody understands the importance of perimeter security. Unfortunately, it still begs the question: where does my network really start and end? The problem is that it is often difficult to know just who has access to your network and who doesn’t. In the Heartland et al situation, the intruders found their way onto several networks and placed software that went undetected for months on end. Once the software was installed, they were on the “inside” and not subjected to same controls one has when trying to get to the inside.

Lesson #5: be just as concerned about what goes out of your network as what comes in.

All of these lessons point to fundamental security concepts: make sure you understand the details, accept that intruders will try just as hard as you, many intrusions are successful using simple exploits, passing an audit doesn’t guarantee your safety, and you should assume you don’t know who is on your network and protect resources accordingly.

Throwing Out Password Masking With the Bathwater, By Keith Royster

2009-07-06T08:47:00.015-04:00

A recent and highly publicized blog is recommending that we stop the practice of password masking. The argument made by the author is that password masking offers little to no security benefit while at the same time creating a frustrating user experience. Even security-famed Bruce Schneier has weighed in on the topic. Specifically, the author notes the following:

Users make more errors when they can’t see what they are typing
Users are more likely to get frustrated or feel less confident, and so abandon their login
To get around these problems, users are more likely to employ insecure password practices such as using overly-simple passwords, or copying and pasting passwords from other locations

The author further states that the primary claimed advantage for masking passwords – that it prevents shoulder surfers from seeing what you type – creates a false sense of security. He correctly points out that a skilled or determined shoulder surfer would simply watch the keys you type, without having to see the characters appear on the screen.

In addition to the author’s points, I would add that masked passwords make it difficult for the user to know if they accidentally have caps-lock enabled. And, lacking any feedback about their typos, users are more likely to accidentally lock their accounts after too many failed logins. This creates not only a negative user experience, but also an unnecessary strain on technical support when they get called about the locked accounts.

All of the author’s points are valid, but in many cases the problem is overstated, the benefits are understated, and the conclusion falsely assumes binary options.

First, the problems described for password masking are exaggerated worst-case scenarios. How often do you really think users get so frustrated with masked passwords that they abandon the site resulting in lost revenue to the site’s owner? Or more pointedly, how often should such problems be attributed to the password masking itself, and not some other poor user interface design? I’m not saying it doesn’t happen, I am just skeptical that the problem is as large as the author claims.

Second, some benefits of password masking are overlooked. The author claims only one benefit – preventing the malicious shoulder surfer from seeing your password on screen – and then argues that this person will just watch you type the keys on your keyboard instead. Here are some additional benefits not explored by the author:

Depending on your typing speed, watching keys as they are typed is more difficult than reading a password onscreen – especially for weak passwords. Someone attempting to watch you type keys is more likely to fail in capturing the entire password, or will require additional tools (e.g. video cameras) to assist him. Masking passwords may not be a perfect solution, but it’s not valueless either.
Accidental password exposure is probably a bigger problem than intentional shoulder surfers. When you are making that next big presentation to coworkers and clients via the office projector, a web share, or within your cube, will you remember to blank your screen before you log in? Or would you prefer to ask your audience to all close their eyes briefly while you log in? Or perhaps you trust them to see your password?

Finally, the author presents the problem as if the solution is binary – we either mask passwords, or we don’t. As some Mac OS X users will tell you, this is a false dichotomy. For example, when setting up a new wireless internet connection, the Mac gives you the option to display the typed or stored password. By default the password is masked, but the user has the option to override this, which can be helpful when you aren’t sure if you fat fingered the password field. Apple doesn’t use this feature everywhere, but perhaps it should.

In conclusion, if you are considering unmasking passwords, make sure you aren’t throwing the baby out with the bath water. The points made by the author have validity, but they describe an opportunity to improve the existing practice of password masking, not a valid reason for abandoning the practice entirely.

The President’s Cyber Security Action PlanBy Jonathan Gossels

2009-06-08T10:43:00.005-04:00

Wow! President Obama and his team of cyber security policy advisors really get it.

When I read the President’s remarks and the background report from which these recommendations were drawn (http://www.whitehouse.gov/assets/documents/Cyberspace_Policy_Review_final.pdf), as a security professional, I can only stand up and applaud.

"This new approach starts at the top, with this commitment from me: From now on, our digital infrastructure - the networks and computers we depend on every day - will be treated as they should be: as a strategic national asset…Protecting this infrastructure will be a national security priority. We will ensure that these networks are secure, trustworthy and resilient. We will deter, prevent, detect, and defend against attacks and recover quickly from any disruptions or damage."

We know that the threats are real. We have all seen the steady stream of reports of attacks on our power systems, telecommunications networks, military systems, and other critical infrastructure. We know that vast numbers of attacks go unreported.

We also know that our military and much of our economy rely on highly vulnerable technology. It is refreshing to see an apolitical recognition of this vital problem. It is heartening to see sound principles installed as cornerstones of the initiative:

־ Protection of privacy and civil liberties
־ Accountability
־ Public private cooperation
־ Research
־ International cooperation

Developing the policies and technologies to effectively secure our critical infrastructure is a monumental task; one that I can imagine will take a generation. President Obama set the right expectations.

“The task I have described will not be easy. Some 1.5 billion people around the world are already online, and more are logging on every day. Groups and governments are sharpening their cyber capabilities. Protecting our prosperity and security in this globalized world is going to be a long, difficult struggle demanding patience and persistence over many years.”

Obviously, the devil is in the details, but publicly recognizing this looming threat to our national security and future prosperity is the first step in addressing the problem.

Using two standards to get one thing done: Better IT security! By Brad C. Johnson & Richard E Mackey Jr.

2009-05-19T11:45:00.002-04:00

Achieving a stable and secure IT environment can be accomplished in a number of ways but at the core, you need a framework that helps to guide you in decision making and helping to set priorities. There are two words that go hand in hand as part of defining this kind of framework: compliance and standards.

Standards provide a well documented way to review your business environment within a particular context and compliance is the act of having proven that you have met the requirements as set out by a particular standard. Let’s grapple with the issues of compliance and standards and use two very well-known standards in PCI and ISO: specifically PCI DSS and ISO 27002.

The PCI Data Security Standard (PCI DSS) consists of 12 mandatory high-level requirements for all organizations that store, transmit, or process payment cards. ISO 27002, also known as ISO 17799, is a security standard of practice. It has 12 different sections that provide best practice recommendations on information security management.

At a high level one might come to the conclusion that you would either use one or the other. In practice, and running your business for the long-term, it would be better to think about using both as the use of one will help with the other. They, as it turns out, have a natural tendency to reinforce good security decisions across each other while at the same time leading to the desired state of being compliant in a specific one. ISO provides a good over-arching security framework while PCI details the expectations to ensure that critical customer information is handled correctly (for the specific purpose of dealing with credit card information).

We believe that the best way to deal with these standards is to adopt a lifecycle approach and remember that the process is something that will be iterated many times: education, assessment, and remediation. A good way to do that is to think of this as a 3-part cycle.

In the first part of the cycle you are trying to educate. Go through the high level sections of each section and try to come to consensus on what each of the them mean to your business and talk about how you deal with them now. This can be achieved in a small amount of time and helps to crystallize your thoughts and to get you all on the “same page” for the more detailed analysis to follow.

In the second part of the cycle you actually perform an assessment: you walk through all of the control requirements and specifically note if you are compliant partially compliant, non-compliant, or not applicable to your business. In those areas where you are deficient, you note what needs to change to get you to a compliant state.

In the last part of the cycle, after you have had time to make changes to those controls that were not in full compliance, you review the remediation steps that have been taken and decide if you are now in the desired state.

The process of going through this cycle will not only educate your organization on where you stand, but give you opportunity to think about each requirement or control objective not only on a one-by-one basis, but also as a whole. You’ll understand what you are doing well, what you are doing poorly, and most importantly, what you are not yet doing at all.

ISO 27001 Certification: Is it worth it?

2009-04-10T12:08:00.004-04:00

Many organizations are searching for a method to demonstrate the strength of their security practices to prospective customers and partners. Many are looking to standards like ISO 27001 and ISO 27002 as the basis for making their security practice statements.

The problem is that even with these international standards, there’s some debate as to what it means to comply and what compliance (and certification of compliance) actually says about the organization being certified.

Before attending a week-long course to certify me as an ISO 27001 Lead Auditor, I thought I understood the meaning and benefits of certification and expected to be a part of a sales drive for ISO 27001 certifications for our clients.

Now, having been through the training, and successfully passing the exam, I am not sure of the answer. I am still convinced that compliance with ISO 27002 is a great thing, and even more convinced that ISO 27001 is CRITICAL to using 27002 correctly. However, what I am not as convinced about is the value of the ISO 27001 certification. Having been a part of a number of what we call ISO 27002 Assessments as well as PCI-DSS On-Site Assessments, I know the value of ISO 27002 and how it can help companies. Further, having spent a week with ISO 27001, I believe that understanding it is critical to successfully implementing a long-term security strategy and implementation plan for any company (regardless of size). Its strength is that it focuses on and requires organizations to be competent in 4 security management areas that are often weak in most companies:

- Asset Identification and Valuation
- Risk Assessment and Acceptance Criteria
- Management Acceptance of these items
- Continual improvement of the security program

Being a consultant by trade and by desire, I’m not interested in playing the part of auditor with all the restrictions to the kinds of advice I can provide and lack of judgment I’m supposed exercise. I value helping my clients and providing valued input and recommendations. The audit process does not and cannot do this. It is there to gather facts and compare it to the standard. It is not there to make security better. So from my standpoint, of one who is qualified to do either an Audit or an Assessment, the Assessment is heads and shoulders more useful to an organization trying to achieve effective security.

That said, there is still a place for getting the ISO 27001 Certification: your customer demands it. If I had a customer who required the certification, and the profit I would gain from them (or future revenues) would outweigh the cost of the Audit, then I'd do it. Otherwise, I'd achieve compliance to the degree I thought practical and derive all the value I could from the assessment and associated consulting.

So my final thoughts on ISO 27001 Certification is: "Do it if you have to.” My thoughts on undergoing an ISO 27001 Assessment is: "Do it as a matter of good business." While the two are not mutually exclusive, they are very different. If you need the certification for some reason, and you can justify the cost, then go for it, but I’d start with an Assessment. Just remember that if you have not done your work at the forefront, you are likely going to fail the Audit and eat a large portion of the costs. You will get no help from the Auditors as to what you need to do to improve, remember they are bound by rules not to provide even vaguely specific advice.

Times are changing Windows isn’t the only OS that needs antivirus By James Doig

2009-03-18T08:44:00.008-04:00

There is a Mac Trojan horse that seems to be making quite a splash in the news. Consumer websites and business websites alike are covering this new malware with feverish intensity. While this isn’t the first malware to be introduced to the Mac, it is still interesting because it comes bundled with costly software.

The Trojan, called OSX.Trojan.iServices.A, is packaged with a pirated version of Apple iWork and was first caught in the wild on January 21, 2009 on BitTorrent trackers. A variant, OSX.Trojan.iServices.B, was found bundled with a pirated copy of Adobe Photoshop CS4 five days later. Tens of thousands of Mac users have downloaded the infected software packages so far. Both Trojan variants seem to be loaded after the user supplies the root password for the install of either iWork or Photoshop. After the install the Trojan connects to the available network connection and checks in with what seems to be a controller server. The attacker now has root access to a host with a broadband connection.

What is particularly clever about this malware? It is packaged with large, and expensive, Mac software files. Because of this the malware writer knows a couple of things about the demographic that is liable to download these files:

1. They will probably have a broadband connection.
2. They are unlikely to have anti-virus installed on their machine.

Granted the current malware seems to rely on a Mac user either navigating the shady underbelly of the Internet or downloading files illegally. However, with the growing popularity of Apple’s Macintosh machines and the success of this Trojan it is likely that we will be seeing more malware written for OSX. The common objections to this thought are that the user base is small when compared to Windows and that it is a waste of resources to run antivirus when there are so few viruses written for the OSX platform.

It is true that the Mac user base is much smaller. As of December 2008 the tally was 5.24% on W3Counter.com. Sure, writers of malware may, for the most part, write for the much larger Microsoft user base. However, 5.24% of the 53,892,847 users referenced in W3Counter.com’s sample is still almost 3 million users. Most of whom will not have any anti-virus installed. That means that once a host is compromised, the compromise will likely go undetected. Even if an IDS picked up suspicious traffic from an OSX host, how would IT respond considering the current trend of thinking? Would they assume that since the host sending the traffic is a Mac that it can’t be infected? How long would that Mac stay infected?

Moreover, it is important to remember, that many software vulnerabilities are portable. What that means is a vulnerability in Microsoft Word is often just as effective on OSX as it is on Windows XP. The same goes for browsers with their numerous plug-ins. This allows a virus to be capable of exploiting vulnerabilities across platforms. A proof-of-concept virus was created in 2006 that did just that on Windows and Linux, and that wasn’t the first. In 2001, the sadmind/ISS worm exploited a vulnerability in SUN Microsystems Solaris Operating System and once established, scanned for and attacked Microsoft IIS Web Servers. While not trivial, it seems the rewards are beginning to outweigh the trouble it takes to create these cross-platform viruses.

The question really boils down to this. How long should Mac administrators wait to protect themselves? The PCI Security Standards Council clearly feels that the threat of malware infection has become real enough for all Operating Systems, and that antivirus software is an integral part of a whole security policy. They now require antivirus software “on all systems commonly affected by malicious software (particularly personal computers and servers)” to become compliant. I, for one, believe they are right.

The Missing Link in Client Side Security By Phil Cox

2009-02-26T16:36:00.008-05:00

Over the last few months, I have been in a number of discussions with people regarding the security issues surrounding web browsers and other web-ish type clients. In all my discussions, we talk about the well-known problems with web applications, phishing, Cross Site Scripting, session stealing, plaintext communication, etc.. We pontificate on the "real" risk associated with the different vectors and potential solutions. In almost all of the conversations, I bring up the lack of plug-in/add-on (plug-ins from now on) management, and my counterpart is stumped for a short while. Why is this?
Because most people just don't do it, and there are few (any?) technical solutions to manage plug-ins at the enterprise level.

We all know that the vast majority of critical security issues in the "browser" space are related to plug-ins. We see new vulnerabilities released regularly regarding remote exploits of plug-ins, yet how many of those vulnerable systems get patched? I dare say, a small few. Because browsers are the universal client for distributed applications, and most browsers sit on corporate networks behind firewalls, they provide the perfect vector to bypass all that perimeter protection. All is needed is a vulnerability, and vulnerable plug-ins (usually) provide that. As a matter of fact, in a recent project for a client, we did research on "remotely exploitable" browser based vulnerabilities, and found that 90% of those were because of vulnerable plug-ins (i.e., Flash, Shockwave, JRE, etc.).

So, what is the missing link? It is the lack of enterprise level plug-in management. Most companies are not doing it, the security conscientious companies are doing it ad-hoc at best, so I ask why? I believe the answer is that there is NO software package that I know of that will perform enterprise level plug-in management. If you are a patch management vendor, then there is an opportunity. If you have a current patch management system, encourage your vendor to integrate plug-in management into its solution.

The Boutique vs The Goliath By Pete McLaughlin

2009-02-16T10:20:00.012-05:00

I consider myself one of the lucky ones. After working at SystemExperts for 6 years as its Director of Business Development, I left in early 2007 to take a position as North America Sales Director for a security practice within a large global consulting firm. As a son of a high-level executive of a Fortune 500 company and a former professional athlete, I thought I had been called up to the consulting world’s version of the Dallas Cowboys in the NFL. When I arrived for my first day in the firm’s newly renovated Boston office complete with leather chairs and Plasma TVs, that sentiment only grew. I had arrived.

A funny thing happened as the newness wore off and I started working the job - eventually, once 401k allocations are set and we decide which health plans best fit our families’ needs, we have to work the job - I discovered that I missed the boutique world. The glitz and glamour of working for the self proclaimed ‘gold-standard’ could not match the opportunity that I have at SystemExperts to roll up my sleeves with quality people of unmatched commitment to the client, not individual careers or quarterly metrics to meet The Street’s expectations.

I enjoyed my time at the large firm and consider myself a better professional because of it. But I am guessing that there are folks out there reading this blog that know exactly what I mean when I say that a perfect storm of operational conference calls to report on the report that you reported, unfortunate internal politics, and an ever growing list of internal processes can get in the way of what you were hired to do. To battle these predictably unpredictable inefficiencies, the goliath charges more and bills at T&M. Here at SystemExperts, we are nimble enough to not have, and for that matter not need, excessive internal processes. This allows us to charge less, do the same if not better work quicker, and conduct that work at a fixed priced. I would imagine that is reflective of other boutiques across varying industries as well.

A 50% employee turn-over rate at the bigger firm makes it difficult to develop and maintain project momentum and client relationship continuity. To battle that, you are asked to sell the company, the project approach, and methodology, not the people. Here at SystemExperts, our people are one of our differentiators and given that our practice has existed longer than all of the Big Four security practices, I do not hesitate to sell not only our company, project approach and methodologies, but the persons working the project. They are some of the best and proud to work for their company.

I have worked in both arenas with equal enthusiasm and passion for success. I am one of the lucky ones. I am thrilled to be back in the boutique consulting world and even more excited that it is with SystemExperts. If that big firm is, in fact, the equivalent of the Dallas Cowboys, consider SystemExperts the Green Bay Packers, a team with admittedly smaller resources but champions and professionals through and through.

P.S. I am a New England Patriots fan.

Back to the Future: Input Validation By Brad C. Johnson

2009-02-01T12:14:00.010-05:00

In the middle of this last year we posted a blog called “Why is this so hard?” It was a short piece emphasizing that doing proper input validation is one of the most fundamental things that can be done to cut down on Web application based exploits: one of the fastest growing exploit areas on the Internet.

We said:

“The design philosophy has to be:

Validate input data wherever possible
Pay as much attention to what’s going into the web application as what’s coming out of it

Input Validation; it’s not sexy. It is not an interesting technological challenge. It is just a simple best practice that makes your web environment much more secure.”

Well, just recently came the announcement of “CWE/SANS TOP 25 Most Dangerous Programming Errors” – see here for more details: http://www.sans.org/top25errors.

Guess what? In their own words “the number one killer of healthy software” is – drum roll please – Improper Input Validation. As we said before and this helps to promote now, assume that all input is malicious. Check it everywhere and every time you either read it or write it.

So what is “it” that we’re checking? Everything! Form data, cookies, anything read over the network, variables set by the server or the application, URL data, email addresses, everything! Check it when you first receive it, check it when you store it, check it when it crosses program boundaries (i.e., from one function to another function), and check it when you read it out of your own data stores.

Many of the problems that attackers are exploiting can be greatly minimized or eliminated by performing thorough input validation all the time. Just do it!

Network Security Tools and Their Limitations By Brad C. Johnson

2008-10-22T09:20:00.008-04:00

There are lots of tools that you can use to help analyze and profile the networked resources you have. There are web scanners like Nikto, WebScarab, and WebInspect; vulnerability scanners like Nessus and ISS and intrusion detection systems like snort. There are packet sniffers like Wireshark (formerly Ethereal) and TCPdump. There are specialty programs like the wireless tools Kismet, NetStumbler, and Aircrack or password cracking programs like Cain and Abel and John the Ripper.

There are several places you can learn about these tools such as http://sectools.org/ and http://www.networksecurityjournal.com/features/open-source-security-tools-applications-resources-041007/, but of course you can use search engines to refine what you are looking for.

You should use as many of these tools that are applicable to your environment as you can. Why? Any tool that makes it easier to administer and monitor your network is good. Any tool that helps you both manage your network and also keep it safer is even better. Of course, if you can use a free public domain or open source tool, instead of having to pay, that is even better still. In any event, using tools is a good use of your time because they can help you identify unexpected changes in your environment and possibly identify specific exposures or vulnerabilities that may exist with minimal effort on your part.

Having said all these glowing things about tools, let’s remember that most of them are only going to find well-known “easy” to identify problems. These network security tools are not going to find subtle problems, they are not going to find combinatorial based vulnerabilities, and they are certainly not going to ferret out architectural or design issues that may plague your hosts, services, or web applications.

If you want to know if you have written secure code, you probably need to perform a code review. If you want to know if your web application ensures that unauthenticated users cannot access data reserved for authenticated users or that authenticated users cannot either view other’s data or escalate privileges, you will need a hands-on assessment done by people who understand both high level design issues and low-level web application protocols. If you want to know if your host or network component like a firewall, router, or web server is properly configured, you are going to need a hands-on review to determine if it is properly hardened.

The bottom line is there is a time and place for everything. Using tools to perform routine scans and analysis on your networked services is something you should be doing on a regular basis. It is important, however, that you don’t mistake this good “daily” hygiene with critically needed in-depth analysis that can only be performed at the hands of real experts.

Remembering Defense-In-Depth Security By Denny Deaton

2008-09-18T16:27:00.001-04:00

One of the recurring topics, in discussions with our clients, is defense in depth security practices. As a good refresher, defense-in-depth simply means a redundant multi-tiered security architecture, which ensures that each layer of technology is independently secure. This alleviates the opportunity for single points of failure and unauthorized access.

In the day-to-day rat race of patching systems, managing firewalls, developing software, meetings and so on the big picture of security within an organization is often forgotten. Do yourself a favor and stop to think about that for a second. This is important to you; regardless of what level in the organization you are or what role you play.

Historically, attacks have occurred primarily at the network and host levels. Hackers targeted firewalls and company networks, then found an unsecured port or unpatched system to further access the internal network. Firewall and system administrators have done a great job of changing that. More times than not systems and firewalls we perform testing on are secure. Yet other components of the technology infrastructure still are not. For example, web sites, wireless devices, mobile devices, and support staff to name a few.

Today, web sites are considered the low hanging fruit when it comes to finding a way into the network. In almost every case with our clients, we find a way into the application and furthermore access to the underlying data, like apples lying on the ground. Software is custom, written by humans, changed sometimes daily and rarely tested or reviewed for security. Time to market is the primary focus in almost every situation. Which means there is more room for error and less time for reviewing it from a security approach.

Another popular attack vector has become social engineering and physical security breaches. It is all too common that we encounter a customer support representative providing login credentials for a flagship application, simply by asking a few questions or making several callbacks.

In summary, enough emphasis cannot be applied to the importance of a defense-in-depth methodology to the overall security within an organization. This effort should be championed by the company’s CSO (or an equal role), and a series of steps should be defined to ensure that the methodology is carried out throughout all tiers within the organization.

Virtual server selection By Phil Cox

2008-07-31T11:41:00.002-04:00

I have been muddling through the "Hype"r-V blogs and emailing that have innundated me over the past couple weeks. I have also taken another look at the free ESXi server from VMWare, and the XenServer 4.2 beta. Being in the midst of looking at all of these, one thing struck me about all of them from a security standpoint: They are all the same!

Let me explain. After having spend hours fiddling and testing each one, security of each boils down to:
- Each has a relitively small hypervisor that may contain bugs
- Each has a main controlling partition that is remotely accessible
- Each can limit who and how you can access the controlling partition

The one caveat I have to this is that the VMWare ESXi server does not have a firewall that can be used to protect the main controlling part of the offering. I do not like this fact.

So what server solution do you choose? I can't tell you that, but what I can tell you is that, from a security standpoint, a knowledgeable admin can secure any of them just as well as the other. From a maturity and functionality standpoint, VMWare and XenServer seem to have the edge right now, but you need linux expertise to understand the innards. If you are a Microsoft shop, then I'd go with Hyper-V and SCVMM.

PCI-DSS Compliance is different than validation By Phil Cox

2008-07-11T17:56:00.004-04:00

An interesting discussion that I have been having of late, is the fact that many people do not really comprehend the difference between PCI-DSS compliance and validation requirements. Here it is in a nutshell:

- Compliance: Everyone has to be compliant to 100% of the PCI-DSS standard 100% of the time, regardless of "level". There is NO distinction between a level 1 and a level 4 in terms of their compliance requirements.

- Validation: A set of things "to do" to assure to another that you are compliant. Typically based on transaction volume and/or type of organization (i.e., service provider, gateway, merchant, etc.). Validation is where the terms level 1,2,3,4 are used. There are different requirements, defined by card brand or acquirer, that must be done for different levels. It should be noted that the existence of the PCI Security Council is a step at making the validation requirement consistent through out the industry.

So, everyone who "stores, processes, or transmits cardholder data" is required to be 100% compliant 7x24, however depending on their business, the validation requirements differ.

The analogy I like to use it speed limit. The law says that you have to "comply" with the speed limit. However, there is only periodic "validation" of that compliance. Not the best analogy, but it gets the point across. So when a level 4 asks me "do I really have to be compliant with 12.1", the answer is "YES!". The real question is, what does it mean to be compliant? For my thoughts on that see my previous post on selecting QSA.

You get what you pay for: QSA Selection By Phil Cox

2008-06-25T22:00:00.003-04:00

Having recently come from my annual QSA re-certification class, it was obvious to me that there are some very large chasms in the interpretation and service level of offerings by QSA vendors. There are some very large companies that are basically selling you a check-box, and in reality are doing nothing to meet the intent of the PCI-DSS. They staff their engagements with very junior people, try to pull data, and then have their QSA "manage" the project and basically sign off on the engagement. You get a report, you get some helpful information, and you get a check-box. What you don’t get is someone that is vested in you making your security better.

I liken it to going to a doctor, and the least expensive doctor will ask you the questions they learned, and ultimately come to a diagnosis based on expedience (i.e., they want your money and really don't care if they get the right diagnosis). A better doctor will have experience, and when you answer the typical questions, have the ability to catch nuances and has the experience to detect problems where you might not. They are vested in an accurate diagnosis, and ultimately improving your health. In the short term, the first doctor is less expensive, but in the long term, the experienced doctor will save you money.

I am convinced more than ever that THE critical part of choosing a QSA is the level of business and security experience in the staff that will do the engagement. As in many things, you are likely to get what you pay for when selecting QSA vendors. This does not mean that the most expensive is the best, but I would argue that the company with the most experienced security staff would likely be the best long term bet. I have yet to have this last thought disproven!

IPv6 and a Practical Security Ramification By Phil Cox

2008-06-25T21:58:00.002-04:00

I was reading a number of the recent Usenix papers on IPv6 transition, and the one thing that sparked a thought was the fact that there really is no "RFC 1918" space in the IPv6 world. I was wondering how many security architectures have a fundamental assumption that "you can’t get there from here"? I know that I use a NAT firewall and private address space as a main aspect of my security architecture, but when I move to IPv6, that will be gone. This does not mean that I will be more vulnerable, as a properly configured firewall will restrict traffic. However, I will have to be more purposeful in blocking traffic, where as now, I rely on a default that it just can’t be done.

Just some food for thought.

Phil

Payment Card Industry: Compliance Overview By Brad C. Johnson

2008-05-15T15:16:00.006-04:00

The Payment Card Industry (PCI) has decided that organizations that transmit, store, or process credit card data, in particular, the Primary Account Number (PAN), be compliant with the PCI Data Security Standard (PCI-DSS). Once you start using payment card data, the compliance is mandatory, all encompassing, and immediate.

The mandate for PCI-DSS compliance has been agreed to by the following card brands: Visa, MasterCard, American Express, JCB International, and Discover Financial Services. Another little item is that there are other protection requirements for ancillary data in the PCI-DSS. The PCI-DSS 1.1 standard can be found at the following URL: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf.

It is important to note that if a company is not compliant, they risk losing their ability to process credit card payments and they may also be fined. It can’t be overstated that from our understanding compliance is mandatory, all encompassing, immediate, and perpetual regardless of how big or small or they type of user you are. Meaning you have to do it, it must be 100%, it starts as soon as you start using cardholder data, and it lasts until the last bit of cardholder data is no longer used. Many companies don’t seem to get how deep and lasting the claws of PCI-DSS are.

PCI requires that anyone under the PCI-DSS prove their compliance via annual assessments. There are four different levels of assessments that can be performed. Which level an organization falls under is roughly determined by how many credit card transactions a company performs coupled with the total value of these transactions as well as the type of entity (i.e., all service providers must pass a Level 1 assessment). Each card brand, not surprisingly, has its own definition for each level: however, they have been merging over time.

It should be noted that many organizations who are required to perform the Annual Self-Assessment Questionnaire often use a third party consulting firm, who specializes in these kinds of assessments, to help them perform the audit to ensure completeness . Failure to pass an assessment may result in having a companies ability to use the credit card(s) revoked.

The process to become and maintain the QSA certification is non-trivial, and arguably one of the most stringent in the industry. PCI is doing their best to ensure the organizations and people doing the assessment work are qualified and able to deliver a quality product.

2007 in Review By Jonathan Gossels

2008-01-02T11:56:00.001-05:00

Every year at this time we share with clients and selected industry leaders the key trends we’ve been seeing over the course of the year. Our conclusions are distilled from a combination of the types of projects we’ve completed and a reflection on the discussions we’ve had with clients and prospective clients about their security needs and concerns.

Overarching Trends

IT Security in the public view

IT Security awareness among the general public has never been higher. The highly visible TJX debacle is illustrative, but hardly an isolated incident. Almost every week sees the announcement that some major corporation or public entity has been breached or has lost control over private data. What is common in nearly every case is that they are woefully unprepared to handle a security incident. They typically have no real plan in place to categorize an incident (high, medium, or low business impact), manage the technical response including determining the extent of the breach, and manage the business response including notifying customers and handling investor and public relations.

Compliance, compliance, compliance and standards based assessments

2007 was a watershed for compliance. It is amazing how fast compliance requirements have come to drive security programs. Just a few years ago compliance was the tail of the dog. For many organizations, compliance now drives the security program.

Take HIPPA for example - it finally happened. Atlanta’s Piedmont Hospital became the poster child for Health Insurance Portability and Accountability Act enforcement when it was audited by Health and Human Services earlier this year. It has been clear to even casual observers that the health care industry has largely ignored the Act’s Privacy and Security Rules regarding the protection of Electronic Protected Health Information (EPHI). This long overdue action has health care providers and the organizations that service them scrambling. We’ve not seen this level of interest in HIPAA assessments since the law was first enacted.

Similarly, merchants are far more security conscious. They have to be. The contractual structure between card acquirers, banks, and the payment card companies rest much of the liability for security problems on the merchants. Smaller merchants need to complete an Annual Self Assessment Questionnaire (self assessing for most small businesses is about as practical as giving yourself an annual physical). Level one merchants need to conduct an annual PCI Data Security Standard (DSS) on site review. For this reason, SystemExperts became a Qualified Security Assessor Company (QSAC) this year and nearly all of our staff Qualified Security Assessors (QSA). If you are not familiar with the PCI Security Standards Council's QSA qualification requirements, they are exacting and detailed.

ISO 17799/27002 compliance continues to grow in importance. It provides organizations with an objective measure of their security stance, enables them to easily communicate the extent and effectiveness of their overall security program, and is recognized and accepted as a high hurdle by prospective customers and business partners. Interestingly, we are finding that we often use the table of contents from the standard as a gauge of completeness even when we are not performing an ISO 17799/27002 review per se. For example, we recently completed a combined ASP/HIPAA review for a company that provides on line medical record management. At the end of several days of detailed discussion, I found myself looking over the ISO table of contents to make sure we hadn’t inadvertently omitted a critical topic.

The more compliance reviews we perform, the more confirmed we become of the fact that good security is good security. These standards are fundamentally consistent in the policies and best practices that they require.

Identity management

With the major security standards and regulations requiring close management of access controls, it is not surprising that identity management is such an important topic. Now, managing user accounts and privileges is nothing new. Every one has been dealing with it since the very beginning of the computer era. What is new - and this is where the identity management products come in – is the recognition of the importance of the management work flow. Specifically, work flow approval process that provides auditable controls over authorization, creation, review, and disablement of user accounts.

Application level vulnerabilities

In past years I’ve noted that web applications continue to be the fastest growing exploit area. That trend is only accelerating. I’m beginning to sound like a broken record on this subject. Traditional web development methodologies are failing to protect sensitive data. Many of these applications are fundamentally flawed in both their design and their implementation. We all know the old software development joke about good, fast, cheap – pick any two. It doesn’t have to apply in this case. It doesn’t take longer or cost more to design and implement an effective authentication mechanism or to make valid assumptions about session management. What is needed is security consciousness or security staff participation early in the application’s lifecycle.

Technology

Removable Media: The explosive innovation that has occurred in the area of removable media with devices like USB flash drives and iPods that can hold large amounts of unstructured data poses a real security threat to many organizations. On the one hand, the uncontrolled use of these devices puts an organization’s intellectual property at risk. Rouge employees can walk off with analytics, client lists, and trade secrets and never be detected. On the other hand, indiscriminate use of these devices violates basic system hygiene practices and might lead to the introduction of a damaging virus or worm into the environment. Many organizations have reacted (largely unsuccessfully) by adopting policies than ban their use. Others try to manage the risk by authorizing designated staff members and systems and adopting a procedure for checking the drives for malware.

Virtualization: Many organizations are exploring the use of virtualization technology (products like VMWare) and are just beginning to wrestle with security implications. Security people tend to like to see application environments physically and logically self contained so we can turn the security knobs appropriately for each one. Properly securing the future highly virtualized environments will be challenging all of us for years to come.

Security Infrastructure: In the same way that corporate and departmental web sites burst onto the scene about ten years ago, suddenly SharePoint servers to store security documents and Wikis for policies and procedures are everywhere. Simply, these are great tools for capturing institutional knowledge and reducing the time and cost of documenting key processes. The Wiki in particular directly addresses a chronic security problem; documentation never keeps pace with actual practices or policies.

Identity Theft Blog Entry By Jonathan Gossels

2007-10-31T11:11:00.000-04:00

Where is the outrage? Security incompetence is putting millions of people at risk for identity theft and there seems to be no accountability at all.

Week after week we see major companies losing control of their customers’ and employees’ private data. This past few weeks saw AT&T notifying present and past employees (I’m aware of one notified person who hasn’t been an employee for eight years!) that a laptop containing their Social Security Numbers, compensation, and home addresses was stolen. Administaff, an HR outsourcing firm, announced virtually the same thing. These instances demonstrate how vulnerable each of us is to identity theft, even though as security professionals we take appropriate measures to safeguard our private data.

I raise these two examples because they share several common characteristics.

In both cases, the company allowed a poorly configured laptop, one that did not enforce the company’s nominal security policy of encrypting confidential data, to be used for processing a large volume of confidential personnel data..

It’s a sad fact that given their size and portability, laptops are often lost and stolen. We can’t prevent that but we can manage how we configure these systems (e.g., requiring encryption if the system handles any sensitive data) and what we prohibit as unacceptable use to reduce these inherent risks.

It is all too common for organizations to extract data sets that contain more sensitive information than is actually needed to accomplish a particular goal. Few organizations have policies and procedures in place to ensure that this unnecessary data is scrubbed before the data set is downloaded or processed. It is far easier to prevent data leakage at the source, rather than the endpoint.

In both cases, the companies failed to keep physical control over laptops that they knew contained extensive confidential information. This is a red flag for poor security awareness and training. The concentrated personal data should have been removed after its use and the laptops should have been properly locked up when not in use.

The final similarity is that both companies acknowledged that they had put employees at a substantial risk of having their identities stolen. Both chose to ameliorate employee/customer concerns about Identity Theft by providing affected people with one year of an Equifax credit monitoring service. Interestingly, the second page of both the AT&T and Administaff letter to employees and customers is identical. That raises an interesting inference; the frequency of these types of breaches is so high that Equifax has standard form letters ready to go and is making a business out of closing the barn door.

Why is this so hard? By Brad C. Johnson

2007-06-20T08:57:00.003-04:00

We all know that there is a lot of pressure on companies to offer new or upgraded services over the Internet. We also know that a lot of this pressure funnels to the development groups that are tasked with quickly (usually, too quickly) releasing functionality that the masses can consume. The fact is, exploiting security vulnerabilities in web facing applications is one of the most common ways in which hackers get access to data or systems that they shouldn’t and is also one of the leading risk areas for identity theft.

A cornerstone of almost any type of web application is input: the simple act of asking the user to enter information for the web application to process. The problem is that too many web applications still fail to validate incoming data. It is one of the leading causes of web application compromise. Why is this obvious requirement routinely ignored?

There are at least three places that input validation can occur:

- at the user’s browser as part of client-side HTML code
(e.g., javascript),
- at the web server
- in the web application itself.

Each of these components has an opportunity to evaluate the data that was supplied for a particular field and then determine if it should be rejected or sent on.

From a security perspective, we would like to see input validated in all three places. In addition, we would like to see the server perform output validation before sending data back to the client. Why do we need to check in all of these components? You need to check in all places because you don’t know where corrupt or malicious data may come from.

To illustrate, you can bypass client-side validation by using a web proxy. You can bypass the server by making calls directly to the web application functions. You can even bypass the web application itself, if you have direct access to the database (or file or data store) on the server. The bottom line is there are a number of places that the data can be corrupted and performing input validation in multiple places ensures that accidental or malicious data is not processed.

Most application developers understand the characteristics of acceptable input. It should be a requirement that those characteristics are always validated for each field – that is, do not assume that you can trust the component that just handed you the data.

Should a first name field allow the “<” or “%” characters? Should a monetary number field allow alphabetic or special characters? Should a credit card or social security field allow escaped command sequences? The answer, of course, to all of these is no.

The design philosophy has to be:

- Validate input data wherever possible
- Pay as much attention to what’s going into the web application as what’s coming out of it

Input Validation; it’s not sexy. It is not an interesting technological challenge. It is just a simple best practice that makes your web environment much more secure.

New OWASP Top 10 Web Application List By Brad C. Johnson

2007-06-06T13:51:00.002-04:00

The Open Web Application Security Project (OWASP) has updated their Top 10 security issues that plague (Internet) web applications. The original version came out in 2004 and through the hard efforts of many members and non members of the OWASP community, the list has been updated to be more consistent as well as more reflective of the current state of web application vulnerabilities.

Following are both the new and old lists.

New 2007 List
A1 - XSS
A2 - Injection Flaws
A3 - Malicious File Execution
(e.g., code that accepts file: PHP, XML, attach)
A4 - Insecure Direct Object References
(e.g., URL or parameter manipulation)
A5 - Cross Site Request Forgery
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage (e.g., poor cookie entropy)
A9 - Insecure Communication
A10 - Failure to Restrict URL Access

New 2007 List: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf

Old 2004 List
A1 - Unvalidated Input
A2 - Broken Access Control
A3 - Broken Authencation and Session Management
A4 - XSS
A5 - Buffer Overflows
A6 - Injection Flaws
A7 - Improper Error Handling
A8 - Insecure Storage
A9 - Denial of Service
A10 - Insecure Configuration Management

The new list is certainly better.

Personally, however, I think getting rid of both Unvalidated Input and Insecure Configuration Management is a mistake as I think they continue to be important web application issues as opposed to Cross Site Request Forgery and Insecure Cryptographic Storage. I think those issues are important, but not worthy of the Top 10.

In addition, I also think that Broken Access Control is far more prevalent and more important than Injection Flaws. I mostly believe that because most injection and XSS issues, as it turns out, can be to a large degree addressed with both input (data flowing from the client to the server) and output (data flowing from the server to the client) filtering.

Embracing PCI for no other reason than... By Pete McLaughlin

2007-04-24T11:26:00.000-04:00

One of my least favorite terms in the business world today is that all too tenuous ‘industry best practices for security.’ What does that really mean? Does ‘industry’ mean the ‘security industry’ or does it mean, for example, the ‘financial services industry?’ So let’s say it refers to the ‘financial services industry.’ Let’s go one step beyond that, does it mean the ‘regional bank industry’ or the ‘mutual fund industry’ or the ‘on-line financial search engine industry?’

It’s business speak, it’s flagrantly overused, and I have grown to despise it. We have let it slip into our everyday vernacular without protest or guilt. And the most disgusting part of it … even though I am far from a fan of the term, I use it. What a hypocrite...

So, I embrace the momentum that the Payment Card Industry standard is gaining. It provides structure to that nebulous term ‘industry standard’ because it does two key things:

- It provides detailed information about what exactly a company needs to do to comply with the standard; and
- It clearly states which companies need to comply (any organization storing, processing, or transmitting a Primary Account Number).

So I say embrace standards such as this one, particularly one backed by competitors that have banded together to solve a problem for an enormous consumer-base. Sure, it has it weaknesses and cynics can snarf at it. But, at the end of the day, it has merit if for no other reason than VISA, American Express, Discover, and MasterCard say so. And if it provides us with something more tangible than ‘industry best practices’ to benchmark our environments against, then I say AMEN brother.

The Power of a Trusted Relationship By Pete McLaughlin

2007-03-13T15:39:00.001-04:00

Many small companies have never engaged a third party to conduct a security review of any sort. The reasons for not doing so range from being too busy, to not budgeting for such an assessment, to not knowing where to start in the vendor selection process, and everything in between. However, some day and some day soon, it will become a high priority and inevitably, those organizations will look to an outside firm for help.

For those companies a rare opportunity abounds: a fresh start.

A small company’s first security assessment is an ideal opportunity to establish a trusted relationship with an outside firm. It is critical to tightly define the scope of the first review and clearly state the business objectives. Doing so will allow small companies to contract with a third party to perform a short and inexpensive engagement with clear objectives and limit the burden placed on already stretched personnel. It is comparable, on a personal level, to engaging a skilled accountant at an established firm for the first time to prepare your family’s taxes. Getting started and establishing a relationship, even at the simplest level, will pay dividends in the future when you will need to leverage the knowledge and experience of an expert or team of experts (e.g. estate planning, being audited, etc).

A security assessment (say, for example, a penetration test of a few IP addresses) may only take a day or two. But, by the end of the vendor selection process and even the shortest of engagements, you will be able to answer some key questions about the firm you selected including:

- Do they offer services catering to small companies like ours?
- Are the consultants as nimble as we are?
- Do they understand our business model and risk context?
- Are they willing to over-deliver?
- Heck – do we like them?

If you answer yes to all of these questions after your first engagement, then you are off to a good start with a new valuable relationship. Securing your environment from multiple threat vectors is critical to the success of your company. Having a trusted outside firm to help you do so as you grow your business is a powerful tool.

War Dialing: The Forgotten Security Threat

2007-02-19T16:07:00.000-05:00

The absolute root of hacking tools, techniques, and software is something called War Dialing: that is, dialing a phone number and trying to exploit the service on the other end. In the early 90’s, a small community of people developed software that would automatically scan phone numbers and categorize the answering system types. These programs run unattended and dial phone numbers and look for recognized devices to attach to. When the program is finished, all the attacker has to do is look at the results and dial the appropriate numbers again, and attempt to gain access to the system or its services.

The goal of those initial dialing efforts was usually to get long distance phone calls for free. At this point of time over 15 years later, War Dialing is still an attractive exploit but for a different reason. Now, it is often used as one of the most successful ways to break into a network. Why? There are lots of sophisticated systems and services that live at the end of a phone line such as network printers, routers, gateways, firewalls, power systems, and desktop systems. In addition, at most companies there are no devices to detect, monitor, or log that a War Dialing effort is occurring and modem-based services are frequently not using any type of encryption, they often do not require any authentication other than dialing the number, and the actions are almost never logged. From a hackers’ point of view, the beautiful thing about War Dialing is that it usually completely bypasses every single security measure that has been put in place for the wired or wireless network.

Your own administrators and vendor support staff often use modems to remotely manage or monitor important services and this type of remote servicing has become increasingly prevalent in this era of outsourcing of IT services.

The bottom line is that most organizations do not perform telephony assessments as part of the security or auditing programs and they should since there are usually many important systems and services that are available at the end of a phone line.

Web Application Identity Theft

2007-01-18T13:06:00.000-05:00

Almost every company has some type of Web presence - ranging from simple brochure sites to sophisticated transaction-oriented applications - and therefore has some type of conduit from the general Internet to company resources and or company data.

The fact is that identity theft and access to confidential or private information through Web applications is one of the fastest-growing exploits on the Internet. The reason is that most Web applications have not been developed with a keen eye toward the hostile Internet environment and are not using appropriately secure methods of authentication and authorization.

Everybody allows a variety of Web protocols and programs directly through their firewalls and routers. Because you cannot stop this traffic from coming through your barrier systems, you have to do an outstanding job of creating an environment that detects malicious attempts that you cannot prevent and prevents as many different types of exploits as possible.

To do this, several areas need to be addressed, each in its own way!

The host that the Web services run on.
The supporting Web server infrastructure.
The Web application itself.

It is important to understand that these components are independent of each other and that effective Web security depends on getting each of them right. Failure of one part could may mean failure of the system as a whole.

For example, a company may have done a good job deploying a minimally configured and well-hardened host and have a well-configured Web server, but if it has a Web application designed using poor assumptions about authentication, authorization or session management, the system as a whole is vulnerable.

To achieve a robust Web presence, you need to look at each of these three areas and perform the testing and remediation measures each requires. Either that, or let some determined intruder or hacker do it for you!

ISO 2700X: A Cornerstone of Security By Jonathan G. Gossels

2006-08-17T12:06:00.000-04:00

For years, organizations have been searching for an objective benchmark to measure the security of potential business partners and to distinguish the security-quality of their own services. While not perfect, ISO 17799 emerged as the standard of choice because it overcame many of the critical deficiencies of SAS 70. Specifically, it provided a comprehensive set of security-related topics and an objective means of measuring compliance.

Building on that success and following the same approach it used with the ISO 900X Quality Assurance standards and ISO 1400X Environmental Management standards, the International Organization for Standardization (ISO) has reserved the 27000 numbering range for a series Information Security Standards. The initial standards are:

- ISO 27000 contains technical definitions used throughout the 2700X series.
- ISO 27001 is a specification for an Information Security Management System (ISMS). ISO 27001:2005 is a re-labeling of BS 7799 part 2. This is the formal standard used for certifying Information Security Management Systems. Its focus is evaluation process rather than content
- ISO 27002 is a re-labeling of ISO 17799, which was originally BS 7799 part 1. This standard contains a Code of Practice consisting of a comprehensive set of information security control objectives and a menu of best-practice security controls.
- ISO 27004 is the number reserved for a future standard covering information security management measurement and metrics.
- ISO 27005 is the number reserved for a future standard covering information security risk management.

To achieve certification, an organization's ISMS must be audited by an assessor who works for a Certification Body. A Certification Body must have been accredited by the National Accreditation Body for the relevant geography. The certification process requires clear segregation of duties in that the organization performing the certification must not have been involved in providing either con-sulting or training.

History has shown that far more organizations used ISO 17799 as a framework for conducting comprehensive security assessments aimed at improving the security and controls of their IT infrastructure rather than for the specific purpose of certification. It is impor-tant to recognize that these standards have value well beyond certification.

Unless there is a clear business reason -- such as customers or partners demanding certification to do business – most or-ganizations would be better served thinking in terms of compliance with ISO 27002 rather than certification to ISO 27001.

Because of the expense, without a clear business driver, there is little incremental value in spending those formal certification dollars. In most cases, having a reputable security firm attest that an organization is “substantially compliant” is more than sufficient.

Just as with ISO 9000, the marketplace is not homogenous. Certain vertical markets such as aerospace or certain supply chains may latch on the ISO 27001 certification as a required fact of life.

The decision to certify or comply is more than one of cost; the two standards measure different things. ISO 27001 assesses whether an organization follows a coarse-grained set of processes that are integral to maintaining the security of an enterprise. Certification assumes that if these processes are in place that effective security automatically follows.

In contrast, 27002 describes a comprehensive set of concrete and fine-grained practices with which an enterprise can be compared.

Bare in mind that both of these standards need to be interpreted within a specific business context taking into account the organiza-tion’s technology, its attractiveness as a target, and its bushiness risk.

The ISO 27001 and ISO 27002 standards are gaining attention for being practical mechanisms for both assessing and asserting good security practices.

Securing Service Oriented Architecture:Ready, Shoot, AimBy Jonathan G. Gossels

2006-04-12T09:44:00.000-04:00

It is almost impossible to pick up an IT technical publication these days without seeing articles touting the virtues of Service Oriented Architecture (SOA). SOA offers the promise of reduced development cost and faster time to market primarily through code reuse. The critical topic that is lost in all of this is security – and securing a SOA environment is challenging.

The term Service Oriented Architecture is frequently bandied about, but it is not broadly understood. A recent survey noted that approximately 50% of IT professionals professed to have some familiarity with the term. Yet, those same respondents overwhelmingly failed to associate the defining attribute, code reuse, with the term. Those findings simply underline that we are in the very early stages of a major technological change.

Now is the time for security professionals to step up and lead their organizations in finding creative solutions to a wide range of problems including:

- The size of applications shrinks in proportion to the number of services available. In order to accomplish the maximum code reuse, services must be designed to be as general as possible. This pressure to produce general purpose services conflicts with application-specific security requirements.

- There is a well established body of best practices for maintaining a secure processing environment. Formal change control procedures are used when new software or systems are added. Only specifically authorized personnel are allowed to implement changes. The opposite is the norm (and vision) for many SOAs.

- In many implementations of SOAs using SOAP and MQ Series, by default, no authentication is performed. However, even if a developer enables Web Services Security, determining what authentication means in the loosely coupled SOA environment is still required.

- One of the problems organizations face with SOAs is that they provide no end-to-end security. In larger SOAs, software infrastructure is used to create a bus processing model that aids in dynamically connecting, mediating and controlling services and their interactions. The beauty (and danger) of this model is that each of the components in the chain is (relatively) unaware of the processing that occurs in the other components; there is no concept of end-to-end control over a SOA processing path.

- It is not uncommon for organizations deploying SOAs to begin by selecting popular infrastructure products. While this approach maximizes application integration, it eliminates business requirements and information security requirements from the selection process – this is a mistake. Often, these requirements cannot reasonably be retrofitted into the environment.

Service Oriented Architectures are a new ballgame and require creative solutions to a wide range of problems. The most important of these solutions are architectural in nature – common infrastructure or replicated infrastructures by security level, how to accomplish mutual authentication, how to manage keys, how components are added to the environment, and who controls data. Our challenge over the next several years is to develop practical solutions to the inherent security problems of SOAs to enable our organizations to reap the benefits of code reuse, shorter time to market, and any-to-any processing interaction. As security professionals, we need to provide leadership now.

Hacking Insight

2006-03-21T12:55:00.000-05:00

Mentioning the word hacker usually elicits a strong response, no matter who you talk to. The Chief Security Officer and virtually anybody on the street will each have something specific to say. The problem with this word is that it detracts from the real issue of making Internet resources more secure because of the emotional baggage tied to that term.

In the real world, it doesn’t matter where an attack is coming from or who is performing it. It might be some teenage misfit with nothing better to do than wreaking havoc on your systems as a way of proving their skills to the world – a common hacker profile. It’s becoming increasingly common, however, that the source of your problems is well funded (such as organized crime or a hostile foreign government), is staffed with security professionals, and is willing to take their time.

What you don’t know could hurt you:

• Most of the work required to successfully hack into your systems does not require actually touching the target systems

• Most of the education you need to successful hack into your systems only requires simple Internet searching

It is best to get past the emotional aspects of the label of the attacker and use a more appropriate term: a determined intruder. Breaking into your systems and services is a project that requires the same methodical approach as any other important business project you take on. Let’s take a look at how a determined intruder takes on the task of getting inappropriate access to your Internet based resources.

For a determined intruder, the four parts of the attack process are as follows:

Part 1: Reconnaissance: Send packets to the target systems and learn how they are setup and what they are running

Part 2: Catalogue & Prioritize: Take the reconnaissance data and determine what is worth researching in more depth

Part 3: Research: Review available documentation, reports, release notes, configuration descriptions, specifications and do online research on who else has dealt with the specific component including known exploits or vulnerabilities

Part 4: Test & Validate: Use the data, techniques, and tools discovered during the research and try to an actual attack or to learn more about the profile of the site

One of the interesting observations about the above methodology is that only the first and fourth steps require sending data to the target site. The second and third steps are “offline” in the sense that the work is done mostly over the Internet (e.g., Google searches and follow-up), but does not include sending data to the target site. What is especially interesting is that historical evidence shows that most of the work in an attack is indeed in these second and third steps. To state what is obvious and yet many people do not appreciate, most of the work performed in a successful attack can not be detected, thwarted, or stopped by you because it is being done on systems that you do not own!

Probably the other most underappreciated fact about attacks is that there is a wealth of information available to anybody willing to invest a little time browsing the Internet. The information is readily available, compelling, and often provides incredibly detailed information that is useful in an attack.

Whether you do it yourself or hire reputable security professionals, all organizations should assume that their Internet resources will at some point become the target of a determined intruder. There are many different types of projects that can assess risk (architectural reviews, security audits or assessments, code reviews) but certainly one of the obvious methods is to simply to proactively do the same thing that a determined intruder would do and profile and test your own systems. It is important to get past the emotional baggage of the word hacker, and focus more methodically on the process of decreasing the risk of your key assets.

Public Domain Tools

2006-01-02T10:03:00.000-05:00

There are literally thousands of tools available to help you evaluate, analyze, or manipulate resources in your IT environment. Some do protocol manipulation or are protocol analyzers (to look at or "sniff" traffic on the network) and some focus on your critical network servers like the name service or the Web server. Some of the tools check the integrity of the files on your systems and some check the integrity of a particular database or special operating system file (like the Windows Registry). Some tools are security- specific like deciphering passwords, encrypting or decrypting files, and doing vulnerability assessments. Also, there are a plethora of tools for all varieties of intrusion detection activities.

Some of these tools are for Windows environments, some for various flavors of UNIX, and some are for both. Some are for your wired environment and others are for your wireless infrastructure.

There are many variables to consider when looking at tools, but often, the most important characteristic is cost; some require license fees and others are free. Most of the free tools are part of what is called the Public Domain (also Shareware and Freeware) and are available from a large number of places on the Internet.

Many organizations don't allow the use Public Domain tools because unlike a commercial product, professional support services are not available and the tools don't have predictable upgrades for problems or new features. However, the overarching reason that most organizations don't allow the use of Public Domain tools is because they don't trust them. They fear that these unvetted tools may create or inject more problems than they purport to solve.

This is a huge problem because while there are many helpful and useful commercial products, a significant number of the vital programs that should be a part of every IT staff's toolkit are indeed free, Public Domain tools. In addition, historically, the Public Domain tool writers tend to be much quicker to respond to new technologies and have also been the leaders in new network and security ideas. If the hackers and determined intruders are using them and therefore one step ahead on everybody else, why shouldn't legitimate security professionals use them as well?

What's needed is some organization or consortium to step up and take responsibility for offering clean, vetted, and signed copies of these programs at a nominal cost so they can be used with confidence and without breaking internal security policy.

Security Skill Certificates

2005-12-15T09:30:00.000-05:00

The Internet community needs to have security skill certifications that are meaningful. Right now, there are a hodgepodge of organizations that offer certifications in a wide variety of areas. Last year there were at least 150 vendor-neutral information security certifications and 20 vendor-sponsored or vendor-specific security certifications.

The fact is, most of these certifications are for entry level skills or are product specific. Don’t get me wrong - we certainly need credentials that demonstrate that someone is competent for the same reason that we hire licensed plumbers or electricians.

What we’re missing is a uniform EXPERT level credential akin to the MD for physicians. And just like in medicine, there should be specialist security certifications to designate significant knowledge beyond the baseline MD-equivalent.

In the security industry right now, there is no way to tell if you're getting a real expert or not.

Welcome!

2005-12-01T01:00:00.000-05:00

Welcome to my SystemExperts Network Security & Thought Leadership Blog!

Here I will periodically post my thoughts on interesting things that are going on in the Internet that relate to security. My plan is to post an entry at least once a month and then let you the blogger readers provide your comments on it. When I move on to the next topic, it's time for my audience to move on as well (i.e., I will close the comments). There are plenty of things to talk about.

Things I might be talking about include Security Skill Certificates, Smarter Wireless Services, Certified Public Domain Tools, Homeland Security, Defense in Depth, Security Standards, Hacking Insights, Job Based Intrusion Detection, and certainly much, much more.

Let the big thoughts in, you will be amazed at how far they can take you!