Periodic PCI Compliance Activities

I am often asked what are the activities companies must perform between PCI assessments in order to remain compliant with the PCI standard. Many people would be surprised to find out that the PCI DSS outlines the specific tasks companies must be doing all the time. The following activities were taken directly from the PCI DSS Version 1.2.1 and outline the periodic procedures companies must take to stay compliant:

Annually

3.6.4 Periodic cryptographic key changes:

• As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
• At least annually

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
• Installing a web-application firewall in front of public-facing web applications.

9.5 Store media back-ups in a secure location, preferably an off-site facility such as an alternate or backup site or a commercial storage facility. Review the location’s security at least annually.

9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.

11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification.

12.1.2 Annual process that identifies threats, vulnerabilities, and results in a formal risk assessment.

12.1.3 Perform a Security Policy review at least once a year and update when the environment changes.

12.6.1 Educate employees upon hire and at least annually.

12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures.

12.9.2 Test Incident Response Plan at least annually.

Bi-Annually

1.1.6 Review firewall and router rule sets at least every six months.

Quarterly

8.5.5 Remove/disable inactive user accounts at least every 90 days.

8.5.9 Change user passwords at least every 90 days.

9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploy a wireless IDS/IPS to identify all wireless devices in use.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Weekly

11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly.

Daily

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).

Immediately

8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.

8.5.4 Immediately revoke access for any terminated users.

12.3.9 Activation of remote-access technologies for vendors only when needed by vendors, with immediate deactivation after use.

Not specified, but suggest annually

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status.

Read more!

SSDs and Performance

Well, if you saw my blog, "The Spin Stops Here," you see that we've already covered topics such as battery life, and the difference between traditional disks and the newer SSDs, among other things. But in this blog, I wanted to cover a couple other issues and facts surrounding SSDs. You may want to read my last blog on SSDs, as I will be using acronyms and information mentioned previously.

Since my last SSD blog, prices have come down and larger drives have become available. I am in transition on my own laptop in running off a SSD with a secondary drive as a SATA disk, mainly for storage and running VMs (not counting the 1.5TB external USB drive I travel with). Also in that time frame I have transitioned to Windows 7, which, may I add, is a fantastic OS, probably the best OS Microsoft has ever released.

So, other than the fact that SSDs are more durable, faster, last longer, consume less power, and create less heat, there are a few things I didn't cover last time. We briefly touched on forensics analysis and how data is actually stored on SSDs, but we didn’t cover what operating systems (specifically Windows 7) are doing to take advantage of SSD technology. Seeing as how SSDs are falling in price (64GB SSDs are nearing $150, which is the size drive I am using), I feel more people will be moving to them, especially in high-end gaming rigs and laptop power users.

Why does the hard drive make such a difference? There are a variety of reasons, and they relate to both the OS and the hardware. We'll start with sequential read and write speeds. My game machine at home has 3 1TB SATA drives in it. Those drives can sustain about 100-120MB/s read speeds and 60-80MB/s write speeds. My SSD is rated at 270MB read/150MB write, which equals a big difference!

The other metric to keep in mind is the random speeds. Sure, when you're moving movies or ISO images or other large files, that’s sequential speed. But what about when your OS is writing a temp file, accessing the pagefile, or accessing data from your user folder? Those random reads depend greatly on access times. SSDs are now reaching blazing fast access times: well under 1ms in many cases (Intel's X25-M is reaching .01ms access times!). Sequential reads are hitting well over 250MB/s and write speeds are consistently over 100MB/s. Even on my old SATA disk, Windows was booting fairly quickly, getting to a login prompt in about 20 seconds. After making the switch to the SSD, my boot time is under 20 seconds, which includes the BIOS checks and logging in. Programs launch in ridiculously faster times, and everything is ultra snappy.

How are SSDs obtaining these speeds? As I talked about in my last blog, it’s because there are no moving parts. The data is stationary and the logic board just says, "Hey, data; come here, the CPU needs you." And off it goes, while with traditional platter drives, the logic board needs to move the read/write heads over a platter, find where bits are stored, and then transfer the data at the speed the platter spins. There's a lot of latency in that type of setup. In some cases, random read times are over 100 times faster at 4KB data chunks, which is what most Windows-based computer files are.

The next big thing is TRIM. To understand TRIM operations, you have to understand, at least a little of how SSDs really work. Last time we went over NAND and NOR memory types. Again, SSDs use NAND flash cell and are made up of millions of these memory cells. They are (in most cases) "clumped" together in 4kb chunks called pages. These pages are written to only at the size they are created, in this case 4kb. These pages can only be deleted or cleared at 128 pages at a time (which when you do the math is 512kb). The biggest issue that SSDs run into is that the drive never knows when a file on the system is deleted. So if you send an item to the recycle bin and then write another file over it, the drive will never know. So the SSD has to keep tabs on every memory cell it has. This is where the ATA-TRIM instruction comes into play.

The great thing about Windows 7 is that it supports TRIM instructions. TRIM instructions are simple. They tell the SSD that certain memory locations are empty so that the SSD doesn’t have to worry about keeping tabs on those locations until data is re-written there. SSDs track those memory locations by adding and dropping them from the Free Block Pool. Before TRIM support, performance degradation was a serious issue and many people were noticing SSDs degrade worse than traditional HDDs. Those were the days that Wipe and Reload would fix your problem. Now those problems are history... mostly. It's still an issue, but a MUCH smaller issue than the pre-TRIM days.

Now, with that understood, we can talk about Random Write times. Random writes are being done all the time on your system, and you've probably never noticed it. If you install an SSD in your system, you'll notice, as many people have, the big difference in speed. A big portion of that increase in speed is attributed to these Random Write times becoming so much faster. In the old mechanical drives there was a section of cache memory installed that ranged from 2-32MB of space. The new 2TB drives are shipping with 64MB of cache. This cache is used as a temporary holding spot, mainly for incoming data, so the drive controller could spin up the platters and move the read/write heads into position (an operation that could take between 5 and20ms). The drive will cache as much data as possible and send a success signal back to the OS so there is minimal interruption in the system.

With SSDs, this cacheing isn’t necessary. The memory pages are instantly available and writing of data takes micro-seconds instead of milli-seconds (ms). Remember what a page file is? It’s that huge 1-4GB file on your C: drive called "pagefile.sys." It looks like 1 file, but actually it contains small chunks of data the OS looks for instead of going to the system memory bus. Over 80% of the reads and writes to the pagefile consists of less than 20KB of data at a time. When Input/Output Operations Per Second (IOPS) are so much faster on SSDs than traditional HDDs, it’s no wonder OS speeds are so much snappier as well. Although I've heard people say not to use a page file when you have a ton of RAM in your machine, you should still use about a 1GB page file for programs that were written to use it.

One of the things Microsoft did to increase performance was decrease the amounts of random writes to disk. But what else can be done to help increase the performance of your SSD and help lengthen its life span? There's a lot actually. For starters, ensure that Disk Defragmenter is disabled. On old HDDs, everyone knew that when you defrag, your system seemed smoother. This is one of the worst things you can do to a SSD, so turn it off. Also, turn off Hibernation and System Restore. You should already have System Restore off; it’s a waste of space and a breeding ground for mal-ware. And if you've ever used Hibernation, you already know it stinks. Also, disable Superfetch and ReadyBoost. These technologies were built for performance increases when using mechanical HDDs and can pose performance issues to your new SSD. It is also recommended to disable Search Indexing in Windows.

Lastly, if you move to a SSD, I would recommend a few other things. The first should go without saying: install your OS from scratch. Don’t try using Partition Magic or some other HDD cloning software. Install a fresh OS, and, if you can, use 2 hard drives. Install your OS to your SSD and install ALL your aftermarket programs to your second drive. Your second drive, if it isn’t a SSD, should be a high RPM disk like a Western Digital VelociRaptor. This way you will keep all your documents and your User folder on your SSD, which are normally the smaller files SSDs fly with. You'll notice big increases in both speed and overall performance.

Read more!

Mitigating Visual Studio Application Manifest Information Disclosure in ClickOnce Deployments

Many would agree that information is an attacker’s best friend when attempting to profile a target and gain information to formulate a more targeted attack. Recently, I’ve come across several Microsoft ClickOnce applications that have leaked an internal domain and username by default. This blog will show you how to remediate the default information leakage.

When deploying Microsoft ClickOnce applications, the Publishing Wizard within Visual Studio creates an Application Manifest file with information about the installation. The file is XML based and has an extension of .application. By default, Visual Studio creates a temporary certificate to sign the ClickOnce manifests and results in a file with contents similar to the following:

If you look at line 8, you will notice that the publisherIdentity reveals the sensitive information (<internal domain name>\<username>). Furthermore, (not visible in the above screen shot) the same information is leaked via the as:X509SubjectName container tag. The workaround to be presented only shows the process by which the default leaked data can be modified, and uses a locally generated certificate. In a production environment, a valid digital certificate from a respected Certificate Authority should be purchased and used instead.

First, we must generate a new certificate that does not contain sensitive information in it to sign our manifests. This can be done using the makecert.exe tool within the .NET SDK. Additionally, we will use pvk2pfx.exe for certificate conversion. These tools are normally installed in C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\. Of course, the Visual Studio directory may have a different version for your installation. Screenshots of the two tools follow:

First we generate a certificate and provide a private key password using the following command:

The result should say “Succeeded” after supplying the passwords. The result should be the creation of MyKey.pvk and MyKey.cer files in the current working directory.

Next, we use the following command and password from the previous step to generate a .pfx (Personal Information Exchange) certificate file:

This step will have created the file MyPFX.pfx in your current working directory. This file can now be used to sign your manifests. To do this, open your project in Visual Studio and view the properties of it by selecting “ Properties…” from the “Project” menu.

From here, choose the “Signing” tab on the left side of the properties page to see something similar to the following (notice the sensitive information shown by default):

Choose the “Select from File…” button on the right, and browse to your newly created MyPFX.pfx file.

Type in the password, and your project should now show your newly created signing information similar to the following:

Save your project, click on the “Publish” tab, and publish using the “Publish Wizard…” or “Publish” buttons. By following the above steps using your own digital certificate, your ClickOnce installation will no longer leak sensitive information by default.

Read more!