Businesses with wifi networks should have policies in place that state under what conditions, if any, smart phones are allowed to connect to its network.  It would be wise to include a specific reference to disabling the “Backup my data” setting, usually found in the Settings/Privacy menu on Android phones.

All administrators using this tool to manage HP hardware over the network should upgrade HP SMH to the latest version in which the flaw has been resolved.

In two independent SharePoint 2010 farms, I’ve encountered errors after changing passwords via the Managed Account functionality. The symptom is that after the change, services will fail to start due to invalid credentials, and you may see errors in the Windows Application Event Log indicating access denied failures.

Each time I’ve seen this problem, there were Windows Services that were set to run as the login with the recently changed password, but at least one of those services was stopped. The solution is that when you are preparing to automate the password change for a service account, ensure that only those services intended to be running are set to run as the managed login, and ensure that those services are in a started state at all times. Your alerting and monitoring system should be configured to watch these services and ensure they are restarted if they stop.

Many organizations have balked at implementing TFA due to the high cost and complexity, and the lack of flexibility of the solutions available.  The landscape is changing quickly – there are new vendors and a better array of options from vendors that have been in the space for ten or more years.

For many years, commercially available TFA solutions meant carrying around a token that displays a number, which is combined with a PIN to produce two factors (something you have: the token, and something you know: the PIN).  Many new, more flexible solutions are becoming available with the recent entry of new participants in the TFA market.  Credit card form factor tokens are easier for some to carry than a traditional key fob.  Grid cards remove the electronic components bringing the price down, and electronic format grids reduce the need for replacement.  Software tokens that uniquely identify a particular phone or computer remove the need to have a user-accessible token altogether.  Out-of-band one time password (OTP) delivery via email, voicemail, or SMS is one of the latest developments in this new move toward flexibility.  Many vendors even support multiple factor types across a single user base, such that one type of user could have hardware tokens, while another set uses grid cards.

Possibly more important to the slow adoption of TFA than lack of flexibility has been the expense of hardware tokens – up to $50 per user every three to five years – on top of the related software licensing costs.  Many TFA vendors have added lower cost options, such as grid cards, software tokens, and hardware tokens that cost less than $10.  There are even lower cost options if you get away from dedicated hardware tokens entirely, for instance, by using out-of-band solutions.

Some of these new solutions are also decreasing the complexity of rollout as well as the time required.  User self-service portals and simplified provisioning are making it a more reasonable proposition to get TFA rolled out to larger numbers of users.

With increased competition in the TFA market, we’re seeing better options at lower costs.  As a result, implementing TFA to protect critical assets is becoming more feasible by the day.

UPDATE 2-11-11:

With Google’s announcement of the coming availability of second factor authentication for its general population of users, it looks like two-factor is hitting the mainstream. Other vendors will have to follow suit or be left behind.

Does your organization currently employ a strong password policy?  Does your organization currently enforce this strong password policy? A strong password should be 14 characters long and should utilize numeric, upper and lower case alphabetical, and symbol characters such as “!@#$%^&*()”.    Most every modern operating system or directory service (LDAP) implementation supports enforcement of strong password complexity.  Administrators should ensure they are utilizing the password history function of their directory service if available, to minimize the potential for password reuse by end users.  For Linux users not utilizing a directory, you can utilize the PAM module provided by the Openwall project, passwdqc, which provides password complexity enforcement.

If your environment allows, utilize password-less authentication using public key encryption provided by either the RSA or DSS.  Most SSH clients and servers support one or both of these methods.  Finally, Ensure that your SSH server does not allow root or Administrator logins.

If your environment already has a firewall in place to facilitate network access control, you should ensure that TCP port 22 is only available to those networks that need access.  If your environment does not have a firewall, OS level packet filtering is available in all modern operating systems.  When thinking about the SSH surface area in your environment, ensure you include devices that are manageable via SSH including routers, firewalls, switches, and other network appliances.

You should really ask yourself why your SSH service is available to the public if you aren’t explicitly providing a shell service to end users.

The documentation is divided into two parts, web and SQL, and together they provide the big picture for a secure environment.  I’ve recently used the documentation to design the security for a SharePoint farm that needs to provide access to multiple outside agencies/partners.  It was much easier to use this documentation than what was provided for the previous version.  I did find a few areas where the documentation could have been more clear, so I wanted to share my findings and see if anyone else has feedback to make the recommendations stronger.

Web Front-End

I found that in a standard Windows network, NetBIOS over TCP/IP could be disabled, according to Microsoft’s recommendation.  The article did not include instructions, but I did find a response on TechNet that describes how it’s done.

The web.config settings could have been described a little more clearly.

• The PageParserPaths should be empty by default.
• Remember that whenever you create a new web application, a new web.config file is created for it, so you will need to verify the settings are still secured.
• I couldn’t find any information about this one, and I’d love it if someone who knows could share their thoughts on how to accomplish this suggestion: “Ensure that Web Part limits around maximum controls per zone is set low.”  Where is this set, and what would be considered low?

I wish this documentation had listed the minimum required permissions for each service, as I’m having to discover these myself.  For instance, the web analytics service is the one that writes diagnostic logs, and that service account needs access to write to the diagnostic logs directory.  It would be great to see a definitive list beyond what was offered in the service accounts documentation.

SQL Back-End

Unless you are using named instances on SQL, it is safe to block access to port UDP/1434.  One measure that the documentation did not mention but is critical to protecting SQL servers in general is that the firewall rules should use a default deny for all inbound access to the SQL servers.  Only the application server(s), Domain Controllers, and the workstations of the DBAs should be able to reach the SQL servers at all.

Please share any other insights you might have or other resources that can help us secure our SharePoint environments better.

Organizations may not have to work hard to initially develop this trust relationship with their customer.  What an organization may not be doing is working hard to maintain this trust relationship.  If the integrity of these assets are challenged, there is a potential risk of destroying this trust relationship, which could be cause for a costly recovery attempt of this customer trust, or complete customer loss.  Ensuring the integrity of your organization’s digital assets should be considered a foundational component of any organization’s security practice.

When we speak of digital assets, we not only include the traditional media data types including images, audio, and video, but all other content produced by your company that exists in a persistent state on disk.  In a web server environment we would most likely be dealing the with following types of data:

• Html, Javascript, CSS, and embedded web objects
• PHP, Perl, .NET, and other application code
• Non-HTML Document types such as PDF or Office files
• Images, Audio, and Video

We were recently employed to review the state of a customer’s environment following a recent intrusion.  As with a portion of the environments we work in today, the services provided included web content and application delivery provided by Apache running on Linux.  While Apache does provide access logging for files requested from it, it does not maintain state regarding the integrity of the files it serves. Following an intrusion, identifying the the attack vector is extremely important in providing future security of this environment but should not be the only consideration.

The following questions need to be asked concurrently:

• What organizational or customer data was exposed?

• Was any data modified and what is the potential impact to our customers?

In high traffic environments, it can be extremely difficult to answer both of these questions quickly, which in turn can prolong the delivery of customer communication or notification for external entities that may have a stake in the exposed data.  To speed up the time to derive an answer to both of these questions, there are two methods that are available to expedite this process.

First, the majority of server operating systems in production today have kernel facilitated auditing capability bundled with the operating system.  Linux provides the Linux Audit Subsystem.  Microsoft Windows Server including 2003 and 2008 provide auditing capability.  Solaris, MacOS X, and the BSD family of operating systems also implement audit facilities.  Each of these respective implementations provide the ability to monitor file access and modification events and produce audit trail which can be used to quickly determine which critical assets were accessed or modified.  Although the deployment of auditing policy is not trivial, the benefit can easily be measured if file integrity is violated and you are able to effectively determine the targeted assets and the associated scope of exposure.

Secondly, organizations should deploy a file integrity monitoring system such as Tripwire or Samhain.  These systems utilize one way cryptographic functions (also known as message digest algorithms) such as MD5, SHA1, SHA2, or Tiger, to create a catalog of computed hashes of  files covered by the monitoring software’s defined policy.  Following the a baseline definition process, these systems monitor filesystem changes against prior hash calculations, and in some cases, against known bad hash values associated with exploit, rootkit code, and other potential malware.   When a change event is discovered, notifications can be delivered to those accountable.

The data generated by each of these tools should be streamed via encrypted transport to a centralized syslog server.   This centralized server should exist in a logically distinct network segment from all other nodes in the environment.   Because this server essentially becomes the gold copy record for file integrity in your environment as related to file assets, extreme care should be used to ensure the validity of logs captured.  This includes utilizing file integrity monitoring and limiting access to those who have a need to know.

The employment of these systems do not provide protection against intrusion but can ease the burden of cleaning up the mess and help organizations identify impact.  While this does not completely mitigate potential loss of trust with your customers, it allows you to effectively measure whether or not their trust was violated and the overall level of exposure.  In the future, we will be providing direction on how these logs can be utilized to provide real-time alerting of an attack in progress, and what you can do to decrease your time to react.

I have been asked that question many times, and I wish the reply I had to deliver was one with a better message.  Unfortunately we often find vulnerable components embedded in commercial products.  Vulnerabilities that can lead to the compromise of the system they are installed in.  We have seen this in both software products that companies are actively shipping, as well as in software and appliances other clients have purchased and installed.  When we request that the vulnerable components be upgraded, the change request very rarely makes it very far up the chain.  The reasoning (when one is actually given) is other “feature enhancements” and new functionality for customers and sales are a higher priority.

While performing security audits against organizations this is an issue that comes up frequently.  What we have seen is that unless the client represents a significant source of revenue or other opportunities for the company shipping vulnerable products, getting them to change can be a very difficult and time consuming process that may not yield major results in any workable time frame.  Baring being a significant revenue source, being a potentially good or bad publicity source could also be a way to get them to be a little more helpful.  For instance having a large scale outage caused by an exploit of one of the vulnerably pieces of software they are using.  However I do not really recommend waiting to be exploited as a viable option.

I am not suggesting that you do not open a support ticket with the company when you do find an issue; however receiving an unworried/unconcerned response is something you should expect.  Having a proof of concept attack against their software that you can show them would be one way to help get their attention, but that can be time consuming and costly.

Instead most organizations are forced to mitigate the issue themselves.  While waiting for the software companies to upgrade or fix the issues you have found, you need to mitigate and create controls around all of the known issues.  In general this can be accomplished through a six step process.

1. Segment your network into different zones based upon function, confidentiality and importance of data, etc.
2. Deploy host based and network based firewalls to restrict access to specific ports, sources, and/or destinations.  The firewalls should restrict both what connections can be made in an attempt to exploit a vulnerability, as well as to limit what damage or access a compromised computer can create.  You do not want a compromised server downloading tools or initiating more attacks if you can help it.
3. Deploy and USE an operational Alerting and Monitoring system, configured to detect outages, error conditions, and anomalies, .  This includes traffic flows, service and device uptime, and SLA measurements, as well as the gathering of syslog data and appropriate snmp-traps.
4. Deploy a network and/or host based IDS to watch for any attempts at exploiting known vulnerabilities or traffic anomalies.
5. Deployment of an event correlation system (such as Cisco’s MARS, RSA’s enVision, or Splunk) to help manage the massive amounts of server, firewall, and IDS logs.
6. Continually monitor, maintain, and manage your environment.  There are no easy “place it and forget it” solutions to security issues.

It is strongly recommended that you read bulletin KB17118, then download and install the patch, called Service Pack 6 Interim Security Software Update 2, from http://www.blackberry.com/go/serverdownloads. The security bulletin also offers a workaround that reduces the functionality of BES but protects the server from exploits of the Attachment Service vulnerabilities.

The affected versions of the server software are BlackBerry Enterprise Server software version 4.1 Service Pack 3 (4.1.3) through 4.1 Service Pack 6 (4.1.6), including the latest maintenance release.