Using Google Public DNS

Configuring your network settings to use Google Public DNS

When you use Google Public DNS, you are changing your DNS "switchboard" operator from your ISP to Google Public DNS.

In most cases, the IP addresses used by your ISP's domain name servers are automatically set by your ISP via the Dynamic Host Configuration Protocol (DHCP). To use Google Public DNS, you need to explicitly change the DNS settings in your operating system or device to use the Google Public DNS IP addresses. The procedure for changing your DNS settings varies according to operating system and version (Windows, Mac or Linux) or the device (computer, phone, or router). We give general procedures here that might not apply for your OS or device; please consult your vendor documentation for authoritative information.

Note: We recommend that only users who are proficient with configuring operating system settings make these changes.

Important: Before you start

Before you change your DNS settings to use Google Public DNS, be sure to write down the current server addresses or settings on a piece of paper. It is very important that you keep these numbers for backup purposes, in case you need to revert to them at any time.

We also recommend that you print this page, in the event that you encounter a problem and need to refer to these instructions.

Google Public DNS IP addresses

The Google Public DNS IP addresses (IPv4) are as follows:

• 8.8.8.8
• 8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

• 2001:4860:4860::8888
• 2001:4860:4860::8844

You can use either number as your primary or secondary DNS server. You can specify both numbers, but do not specify one number as both primary and secondary.

You can configure Google Public DNS addresses for either IPv4 or IPv6 connections, or both.

Changing your DNS servers settings

Because the instructions differ between different versions/releases of each operating system, we only give one version as an example. If you need specific instructions for your operating system/version, please consult your vendor's documentation. You may also find answers on our user group.

Many systems allow you to specify multiple DNS servers, to be contacted in a priority order. In the following instructions, we provide steps to specify only the Google Public DNS servers as the primary and secondary servers, to ensure that your setup will correctly use Google Public DNS in all cases.

Note: Depending on your network setup, you may need administrator/root privileges to change these settings.

Microsoft Windows

DNS settings are specified in the TCP/IP Properties window for the selected network connection. 

Example: Changing DNS server settings on Microsoft Windows 7

1. Go the Control Panel.
2. Click Network and Internet, then Network and Sharing Center, and click Change adapter settings.
3. Select the connection for which you want to configure Google Public DNS. For example:
   • To change the settings for an Ethernet connection, right-click Local Area Connection, and click Properties.
   • To change the settings for a wireless connection, right-click Wireless Network Connection, and click Properties.
   If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
4. Select the Networking tab. Under This connection uses the following items, select Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6) and then click Properties.
5. Click Advanced and select the DNS tab. If there are any DNS server IP addresses listed there, write them down for future reference, and remove them from this window.
6. Click OK.
7. Select Use the following DNS server addresses. If there are any IP addresses listed in the Preferred DNS server or Alternate DNS server, write them down for future reference.
8. Replace those addresses with the IP addresses of the Google DNS servers:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
9. Restart the connection you selected in step 3.
10. Test that your setup is working correctly; see Testing your new settings below.
11. Repeat the procedure for additional network connections you want to change.

Mac OS X

DNS settings are specified in the Network window. 

Example: Changing DNS server settings on Mac OS 10.5

1. From the Apple menu, click System Preferences, then click Network. 
2. If the lock icon in the lower left-hand corner of the window is locked, click the icon to make changes, and when prompted to authenticate, enter your password.
3. Select the connection for which you want to configure Google Public DNS. For example:
   • To change the settings for an Ethernet connection, select Built-In Ethernet, and click Advanced.
   • To change the settings for a wireless connection, select Airport, and click Advanced.
4. Select the DNS tab.
5. Click + to replace any listed addresses with, or add, the Google IP addresses at the top of the list:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Click Apply and OK.
7. Test that your setup is working correctly; see Testing your new settings below.
8. Repeat the procedure for additional network connections you want to change.

Linux

In most modern Linux distributions, DNS settings are configured through Network Manager.

Example: Changing DNS server settings on Ubuntu

1. In the System menu, click Preferences, then click Network Connections.
2. Select the connection for which you want to configure Google Public DNS. For example:
• To change the settings for an Ethernet connection, select the Wired tab, then select your network interface in the list. It is usually called eth0.
• To change the settings for a wireless connection, select the Wireless tab, then select the appropriate wireless network.
3. Click Edit, and in the window that appears, select the IPv4 Settings or IPv6 Settings tab.
4. If the selected method is Automatic (DHCP), open the dropdown and select Automatic (DHCP) addresses only instead. If the method is set to something else, do not change it.
5. In the DNS servers field, enter the Google Public DNS IP addresses, separated by a space:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Click Apply to save the change. If you are prompted for a password or confirmation, type the password or provide confirmation.
7. Test that your setup is working correctly; see Testing your new settings below.
8. Repeat the procedure for additional network connections you want to change.

If your distribution doesn't use Network Manager, your DNS settings are specified in /etc/resolv.conf.

Example: Changing DNS server settings on a Debian server

1. Edit /etc/resolv.conf:

   sudo vi /etc/resolv.conf

2. If any nameserver lines appear, write down the IP addresses for future reference.
3. Replace the nameserver lines with, or add, the following lines:
   For IPv4:

   nameserver 8.8.8.8
   nameserver 8.8.4.4

   For IPv6:

   nameserver 2001:4860:4860::8888
   nameserver 2001:4860:4860::8844

4. Save and exit.
5. Restart any Internet clients you are using.
6. Test that your setup is working correctly; see Testing your new settings below.

Additionally, if you are using DHCP client software that overwrites the settings in /etc/resolv.conf, you will need to set up the client accordingly by editing the client's configuration file.

Example: Configuring DHCP client sofware on a Debian server

1. Back up /etc/resolv.conf:

   sudo cp /etc/resolv.conf /etc/resolv.conf.auto

2. Edit /etc/dhcp3/dhclient.conf:

   sudo vi /etc/dhcp3/dhclient.conf

3. If there is a line containing domain-name-servers, write down the IP addresses for future reference.
4. Replace that line with, or add, the following line:
   For IPv4:

   prepend domain-name-servers 8.8.8.8, 8.8.4.4;

   For IPv6:

   prepend domain-name-servers 2001:4860:4860::8888, 2001:4860:4860::8844;

5. Save and exit.
6. Restart any Internet clients you are using.
7. Test that your setup is working correctly; see Testing your new settings below.

Routers

Every router uses a different user interface for configuring DNS server settings; we provide only a generic procedure below. For more information, please consult your router documentation.

Note: Some ISPs hard-code their DNS servers into the equipment they provide; if you are using such a device, you will not be able to configure it to use Google Public DNS. Instead, you can configure each of the computers connected to the router, as described above.

To change your settings on a router:

1. In your browser, enter the IP address to access the router's administration console. 
2. When prompted, enter the password to access network settings.
3. Find the screen in which DNS server settings are specified. 
4. If there are IP addresses specified in the fields for the primary and seconday DNS servers, write them down for future reference.
5. Replace those addresses with the Google IP addresses:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
6. Save and exit.
7. Restart your browser.
8. Test that your setup is working correctly; see Testing your new settings below.

Mobile or other devices

DNS servers are typically specified under advanced wi-fi settings. However, as every mobile device uses a different user interface for configuring DNS server settings, we provide only a generic procedure below. For more information, please consult your mobile provider's documentation.

To change your settings on a mobile device:

1. Go to the screen in which wi-fi settings are specified.
2. Find the screen in which DNS server settings are specified.
3. If there are IP addresses specified in the fields for the primary and seconday DNS servers, write them down for future reference.
4. Replace those addresses with the Google IP addresses:
   • For IPv4: 8.8.8.8 and/or 8.8.4.4.
   • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844
5. Save and exit.
6. Test that your setup is working correctly; see Testing your new settings below.

Testing your new settings

To test that the Google DNS resolver is working:

1. From your browser, type in a hostname (such as http://www.google.com/). If it resolves correctly, bookmark the page, and try accessing the page from the bookmark. If both of these tests work, everything is working correctly. If not, go to step 2.
2. From your browser, type in a fixed IP address. You can use http://18.62.0.96/ (which points to the website http://www.eecs.mit.edu/) as the URL.^* If this works correctly, bookmark the page, and try accessing the page from the bookmark. If these tests work (but step 1 fails), then there is a problem with your DNS configuration; check the steps above to make sure you have configured everything correctly. If these tests do not work, go to step 3.
3. Roll back the DNS changes you made and run the tests again. If the tests still do not work, then there is a problem with your network settings; contact your ISP or network administrator for assistance.

* Google thanks MIT for granting permission to use this URL for the purposes of testing web connectivity.

Diagnosing resolution problems

If you are encountering problems when resolving particular names, and want to verify whether the problem is with Google Public DNS, please try running the following diagnostic procedures. If you want to report a problem to the Google Public DNS user group, please copy and paste the results of the commands in your email. This information is vital to help us to identify the cause of the problem.

Step 1: Check to see if the authoritative nameservers are correct

If Google Public DNS (or any open resolver) has trouble resolving a site, or returns inconsistent answers, sometimes it is because the authoritative nameservers are having trouble. There are various tools and sites to help you check this.

Some users (and Google Public DNS engineers) have found intoDNS very helpful. For example, if you have trouble visiting www.example.com, visit intodns.comand enter example.com (the domain for www.example.com), or visit http://intodns.com/example.com directly.

Additionally, DNSViz is useful for diagnosing DNSSEC related issues. For example, visit dnsviz.net and enter example.com (the domain for www.example.com), or visit http://dnsviz.net/d/example.com/dnssec/ directly.

If these tools identify a nameserver configuration issue, please contact the owner of the nameserver to fix it.

If none of these tools finds any issue with the nameserver, continue to step 2.

Step 2: Verify that your client can communicate with the Google Public DNS servers

IPv4

Open a command prompt, and run the following command:

On Windows

tracert -d 8.8.8.8

On Mac OS X

/usr/sbin/traceroute -n -w 2 -q 2 -m 30 8.8.8.8

On Linux

sudo traceroute -n -w 2 -q 2 -m 30 8.8.8.8

If the last line of the output does not list 8.8.8.8 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 8.8.8.8 as the final hop, continue to step 3.

IPv6

Open a command prompt, and run the following command:

On Windows

tracert -d 2001:4860:4860::8888

On Mac OS X

/usr/sbin/traceroute6 -n -w 2 -q 2 -m 30 2001:4860:4860::8888

On Linux

sudo traceroute -n -w 2 -q 2 -m 30 2001:4860:4860::8888

If the last line of the output does not list 2001:4860:4860::8888 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Try configuring Google Public DNS for IPv4 to diagnose whether the problem is due to IPv6 connectivity on your network. If IPv4 works for you, you may want to revert your IPv6 configuration and use Google Public DNS with IPv4 exclusively. Otherwise, please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 2001:4860:4860::8888 as the final hop, continue to step 3.

Step 3: Verify that Google Public DNS can resolve the selected hostname

In the following steps, replace www.example.com. with the name that you had difficulty resolving. (Put a period at the end of the name to avoid problems with domain suffixes and search lists.)

IPv4

At the command prompt, run the following command:

On Windows

nslookup -debug www.example.com. 8.8.8.8

On Mac and Linux

dig @8.8.8.8 www.example.com.

If the output shows an answer section with an A record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output does not show an answer for the hostname, continue to step 4.

IPv6

At the command prompt, run the following command:^*

On Windows

nslookup -debug -type=AAAA www.example.com. 2001:4860:4860::8888

On Mac and Linux

dig @2001:4860:4860::8888 www.example.com. AAAA

If the output shows an answer section with an AAAA record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output shows an answer section with an A (IPv4) record for the hostname, then Google Public DNS is able to resolve the name, but the host and/or its nameserver are not configured to return IPv6 results. If you want to verify that you are correctly receiving AAAA records, you can use the hostnameipv6.google.com as a generic test.

If the output for ipv6.google.com, or another host for which you are certain IPv6 records exist, does not show an answer, continue to step 4.

* Note: Google properties will not return AAAA records for all users. Please see the Google over IPv6 page for more information about whether your system qualifies.

Step 4: Verify that Google Public DNS can resolve the selected hostname without performing DNSSEC validation

Google Public DNS performs DNSSEC validation for all DNS queries by default. When a nameserver fails DNSSEC validation, Google Public DNS returns SERVFAIL. To verify whether Google Public DNS can resolve the hostname without performing DNSSEC validation, run the following command:

On Windows

Unfortunately, nslookup does not support DNSSEC and cannot help diagnosis here. Continue to step 5.

On Mac and Linux

IPv4

dig @8.8.8.8 www.example.com. +cd

IPv6

dig @2001:4860:4860::8888 www.example.com. AAAA +cd

If you cannot get a successful result without DNSSEC validation either, continue to step 5.

If you get a successful result, this usually indicates a DNSSEC misconfiguration at the nameserver. Please make sure that you have followed through step 1. If none of the tools finds any issue with the nameserver, continue to step 5.

Step 5: Verify that another open resolver can resolve the selected hostname

At the command prompt, run one of the following commands:

On Windows

nslookup www.example.com. 4.2.2.1
nslookup www.example.com. 4.2.2.2
nslookup www.example.com. 208.67.222.222
nslookup www.example.com. 208.67.220.220

On Mac and Linux

dig www.example.com. @4.2.2.1
dig www.example.com. @4.2.2.2
dig www.example.com. @208.67.222.222
dig www.example.com. @208.67.220.220

(The first two commands test Level 3's DNS servers. The last two commands test OpenDNS's DNS servers.)

If you are unable to get a successful result, this means that there is most likely a problem with the server you are trying to contact. Wait some time and try running the tests again. This may be a temporary problem on the server's side that will likely resolve itself eventually. If it does not, you should contact the owner of the server.

If you are able to get a successful result, there may be a problem with Google Public DNS. Please follow the directions here to report an issue to the Google Public DNS team, and include the output of the commands you ran in the report.

Switching back to your old DNS settings

If you had not previously configured any customized DNS servers, to switch back to your old settings, in the window in which you specified the Google IP addresses, select the option to enable obtaining DNS server addresses automatically, and/or delete the Google IP addresses. This will revert your settings to using your ISP's default servers.

If you need to manually specify any addresses, use the procedures above to specify the old IP addresses.

If necessary, restart your system.

Daily Technotips: How to Implement Group Policy Security Filtering?

The most misleading thing about Group Policy is its name—Group Policy is simply not a way of applying policies to groups! Instead, Group Policy is applied to individual user accounts and computer accounts by linking Group Policy Objects (GPOs), which are collections of policy settings, to Active Directory containers (usually OUs but also domains and sites) where these user and computer accounts reside. So the newbie’s question concerning Group Policy is usually, “How can I get this GPO to apply to this group?” The answer to this question is: by implementing security filtering.

Understanding Security Filtering

Security filtering is based on the fact that GPOs have access control lists (ACLs) associated with them. These ACLs contain a series of ACEs for different security principals (user accounts, computer accounts, security groups and built-in special identities), and you can view the default ACL on a typical GPO as follows:

1. Open the Group Policy Management Console (GPMC)
2. Expand the console tree until you see the Group Policy Objects node.
3. Select a particular GPO under the Group Policy Objects node.
4. Select the Delegation tab in the right-hand pane (see Figure 1).

Figure 1: Viewing the ACL for the Vancouver GPO using the Delegation tab

For a more detailed view of the ACEs in this GPO ACL, click the Advanced button to display the familiar ACL Editor (Figure 2):

Figure 2: Viewing the ACL for the Vancouver GPO using the ACL Editor

An obvious difference between these two views is that the ACL Editor displays the Apply Group Policy permission while the Delegation tab doesn’t. This is because the Delegation tab only displays ACEs for security principles that actually process the GPO, and that implicitly means those security principals have the Apply Group Policy permission set to Allow. More specifically, if you want a GPO to be processed by a security principal in a container linked to the GPO, the security principal requires at a minimum the following permissions:

• Allow Read
• Allow Apply Group Policy

The actual details of the default ACEs for a newly created GPO are somewhat complex if you include advanced permissions, but here are the essentials as far as security filtering is concerned:

Security Principal	Read	Apply Group Policy
Authenticated Users	Allow	Allow
CREATOR OWNER	Allow (implicit)
Domain Admins	Allow
Enterprise Admins	Allow
ENTERPRISE DOMAIN CONTROLLERS	Allow
SYSTEM	Allow

Note that Domain Admins, Enterprise Admins and the SYSTEM built-in identity have additional permissions (Write, Create, Delete) that let these users create and manage the GPO. But since these additional permissions are not relevant as far as security filtering is concerned, we’ll ignore them for now.

The fact that Authenticated Users have both Read and Apply Group Policy permission means that the settings in the GPO are applied to them when the GPO is processed, that is, if they reside in a container to which the GPO is linked. But who exactly are Authenticated Users? The membership of this special identity is all security principals that have been authenticated by Active Directory. In other words, Authenticated Users includes all domain user accounts and computer accounts that have been authenticated by a domain controller on the network. So what this means is that by default the settings in a GPO apply to all user and computer accounts residing in the container linked to the GPO.

Using Security Filtering

Let’s now look at a simple scenario where you might use security filtering to resolve an issue in Group Policy design. Figure 3 below shows an OU structure I developed in a previous article. Note that the Vancouver top-level OU has three departments under it defined as second-level OUs, with user and computer accounts stored below these departments in third-level OUs:

Figure 3: Sample OU structure for Vancouver office

Let’s say that of the fifteen users who work in the Sales and Marketing Department in Vancouver, three of them are senior people who have special requirements, for example access to certain software that other people in the department shouldn’t have access to. Such software could be provided to them by publishing it in Add or Remove Programs using a user policy-based software installation GPO. The trouble is, if you link this GPO to the Sales and Marketing Users OU then all fifteen users in the department will have access to it through Add or Remove Programs. But you only want this special group of three users to be able to access the software, so what do you do? 

You could create another OU beneath the Sales and Marketing Users OU and call this new OU the Senior Sales and Marketing Users OU. Then you could move the user accounts for the three senior employees to this new OU and create your software installation GPO and link it to the new OU. While this approach will work, it has several disadvantages:

• It makes your OU structure deeper and more complicated, making it harder to understand.
• It disperses user accounts into more containers making them more difficult to manage.

A better solution is to leave your existing OU structure intact and all fifteen Sales and Marketing users in the Sales and Marketing Users OU, create your software installation GPO and link it to the Sales and Marketing Users OU (see Figure 4), and then use security filtering to configure the ACL on the software installation GPO to ensure that only the three senior users receive the policy.

Figure 4: Senior Sales and Marketing Users Software Installation GPO

To filter the software installation GPO so that only users Bob Smith, Mary Jones, and Tom Lee receive it during policy processing, let’s first use Active Directory Users and Computers to create a global group called Senior Sales and Marketing Users that has only these three users as members (see Figure 5):

Figure 5: Membership of the Senior Sales and Marketing Users global group

Note that you can store this security group in any container in the domain, but for simplicity you’ll probably want to store it in the Sales and Marketing Users GPO since that’s where its members reside.

Now go back to the GPMC with the software installation GPO selected in the left-hand pane, and on the Scope tab of the right-hand pane, remove the Authenticated Users special identity from the Security Filtering section and then add the Senior Sales and Marketing Users global group (Figure 6):

Figure 6: Filtering the GPO so it only targets the Senior Sales and Marketing Users group

That’s it, we’re done! Now when policy is processed for a user account residing in the Sales and Marketing Users OU, the Group Policy engine on the client will first determine which GPOs need to be applied to the user. If the user is a member of the Senior Sales and Marketing Users security group, the following GPOs will be applied in the following order (assuming we haven’t used blocking or enforcement anywhere):

1. Default Domain Policy
2. Vancouver GPO
3. Sales and Marketing GPO
4. Sales and Marketing Users GPO
5. Senior Sales and Marketing Users GPO

The Power of Security Filtering

The power of security filtering is that it allows us to simplify our OU structure while still ensuring that Group Policy is processed as designed. For example, in my original OU structure for Vancouver (see Figure 3 above) I created separate OUs for three departments in that location, namely the IT Department, Management, and Sales and Marketing. In Toronto however I could have taken a different approach and lump all my users and computers together like this (Figure 7):

Figure 7: Toronto has a simpler OU structure than Vancouver

Then I could group user and computer accounts in Toronto into global groups like this:

• IT Department Users
• IT Department Computers
• Management Users
• Management Computers
• Sales and Marketing Users
• Sales and Marketing Computers

I could then create GPOs for each group of users and computers in Toronto, link these GPOs to the appropriate container, and use security filtering to ensure they are applied only to the desired security principals (Figure 8):

Figure 8: Using Group Policy to manage users in Toronto

The main downside of this approach is that as you flatten your OU structure you can end up with lots of GPOs linked to each OU, which can make it harder at first glance to figure out which policies are processed by each user or computer unless you examine in detail the security filtering setup

http://dailytechnotips.blogspot.in/

Microsoft: Financial Services: A Survey of the State of Secure Application Development Processes

The financial services industry is one of the world’s largest industries by monetary value, and an industry which has a direct impact on the lives of billions of people around the world. Organizations in the financial services industry handle trillions of transactions each year involving sensitive information about individuals,companies, and other third parties. To help protect this sensitive information it is important that financial services organizations are developing, procuring, and using software applications that have been developed with security in mind.

Microsoft commissioned an independent research and consultancy firm, The Edison Group, to examine the current state of application development in the financial services sector from a security perspective. Their report – Microsoft Security Development Lifecycle Adoption: Why and How – is available today.

The paper was developed following in-depth interviews with Chief Security Officers and senior executives representing some of the leading banks and financial services companies in the United States. Some highlights from the paper:

• The Edison Group examined the usage of the Microsoft Security Development Lifecycle (SDL) and how it has been integrated into the software design life cycles of financial services companies.
• The study describes the business benefits of using the SDL, along with adoption approaches and integration methods.
• The adoption maturity of the Security Development Lifecycle (SDL) in participating organizations ranged from highly refined through years of implementation, to a brand new adopter about to begin integrating the SDL into the development processes.
• The paper also includes two case studies, one illustrating the use if the SDL in a Microsoft Windows based environment, and one illustrating the adoption of the SDL in an open source development environment.

In addition to these highlights, the Edison Group found that using a software development process, such as the SDL, to help developers build more secure software can also help address security compliance requirements. For example, the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) recognized the need for standards around security development processes and developed ISO/IEC 27034-1. This international standard is the first of its kind to focus on the processes and frameworks needed to build a comprehensive software security program. Earlier this year, Microsoft announced through its Declaration of Conformity that Microsoft’s SDL conforms to ISO 27034-1. Organizations using the Microsoft SDL to develop more secure software may already be conformant to the standard.

In the United States financial services sector, many of the largest companies came together in 1996 to form BITS, a division of the Financial Services Roundtable. BITS is an organization that addresses threats and opportunities relevant to the financial services sector, particularly those related to cyber-security. In 2012, the BITS Software Assurance Framework was created to document the importance of secure development practices and to provide guidelines that financial services organizations can use to implement these practices more fully.  The Software Assurance Framework was developed to help financial institutions better follow secure development practices and avoid the risks outlined above.

The Framework is rooted in education, integration of security in design using standards and threat modeling, best practices for coding, focused and comprehensive testing and followed with important implementation and response practices.  The Framework was developed in collaboration with Microsoft, and integrates the Microsoft Security Development Lifecycle at the foundation.

According to Paul Smocer, BITS president, “Building safe software is a necessity, a priority and a complex process for financial institutions.  The BITS Framework offers a practical approach to software security through strong design, implementation and testing processes.”
If you are responsible for the development or procurement of software for companies operating in the financial sector, then I strongly encourage you to check out this new whitepaper and the many free security development resources available at www.microsoft.com/sdl.

A Bright Spot in Tech’s Gender Gap

The technology world is still run by men. They have more than 80 percent of the software developer jobs, according to the U.S.  Bureau of Labor Statistics. And they hold most of the leadership positions.

But there’s good news for the Marissa Mayers of the world. The rare woman who does manage to hack her way to a top technology job is paid the same on average as a man in that position, as long as they have the same experience, according to a report by Dice, which tracks corporate compensation. That’s been true since at least 2007, Dice found as part of historical research for Bloomberg.com.

The study, which examined information-technology jobs in various industries, found that while there’s equality for men and women in comparable positions, women tend to end up in less lucrative jobs. Women in those jobs make an average salary of $87,527, while men make $95,929, according to Dice. If only there were more ladies leading teams.

“It’s obviously very encouraging that women in the same position are making the same amount, but why do they end up in different positions?” Shelley Correll, a Stanford University professor who specializes in gender research, said in an interview.

Sheryl Sandberg, Facebook’s chief operating officer and “Lean In” author who is on a whirlwind media tour to promote her book about female business leadership, has said the gap is a result of a combination of factors. Many women leave the workforce before they have to, decide not to take on larger projects, or lack the confidence in their qualifications to apply for promotions, according to Sandberg. So she’s been advocating for women to be more assertive at the office.

Besides equal pay for men and women in the same jobs, there is another commonality between the genders: Dice found that nearly half of all male and female business professionals were not satisfied with how much money they made.