NATIONAL HARBOR, Md. — Fannie Mae was at a standstill, stuck between risk and a flat network. 

The lending company's data centers were split into zones with traffic traveling through choke points. But it was maxed out because zones were too big, said Clayton Mascarenhas, director of information security engineering and operations at Fannie Mae, while speaking last week at a Forrester event in National Harbor, Maryland.

Splitting data centers into zones mitigates the potential spread of malicious activity.

But Fannie Mae's segmented zones were large enough, a bad actor could cause significant damage if it infiltrated the network. 

There was the option of creating additional choke points, but the re-architecting process it would demand left too much room for potential error, according to Mascarenhas. 

Fannie Mae instead chose micro-segmentation — the process of configuring controls around smaller groups of individual hosts — working off granularity and dynamic adaptation. 

The lender knew the concept of segmentation, a security strategy for segmenting computer networks, was nothing groundbreaking. Micro-segmentation, however, could absolve it from potential security woes. 

Granularity allows "fine grain" policy-writing that can be associated with an application and pushed down to a workload, Mascarenhas​ said. Dynamic adaptation is based on abstraction, intelligence and automation to make changes and push it to the host. 

The transition to micro-segmentation was not without trial and error. Here are 10 lessons Mascarenhas took away from the process: 

1. Engage with the application teams very early into the process. 

Mascarenhas needed his application teams' buy-in because "you're going into their domain." He suggested workshops and speaking to teams in terms of applications, not security. 

2. Invest in training and workshops. 

The first workshop Mascarenhas carried out was tracking traffic with the lending company's application teams. "They own this, you don't," he said.

During this time, teams will likely see things "that they shouldn't have allowed." 

3. Don't trust the configuration management database. 

To avoid headache later on in the micro-segmentation process, Mascarenhas says to validate everything.

"Do not trust what's written in CMDB," he said, or configuration management database. 

4. Set a core team. 

The micro-segmentation team should include input from the vendor's infosec experts, in Fannie Mae's case, Illumio. There should also be a platform team to help the vendor and application teams identify platform services traffic and policy testing.

The application team, a key player, needs to designate a person of contact.

The final group of the core team is the infosec operations support team for post-enforcement policy reviews and adjustments. 

5. Deploy workload agents. 

Fannie Mae made the initial error of going down the line of application teams instead of operating systems.

Mascarenhas realized that because new versions of applications are continuously rolled out, the process was constantly behind. However, companies only run a handful of operating systems and versions. 

6. Start with management services when building policies. 

Granular security policies shouldn't be written for everything an application team can do. Instead, Mascarenhas recommended writing policies based on what management services do for a particular application team. 

7. Move onto core shared services. 

An individual policy cannot be written for every application team, there are just too many, said Mascarenhas.

What companies can do instead is write policies based on environments. Fannie Mae's environments include a quarantine, production, semi-quarantine and test environments.

We just labeled an application with one of the groups so it [didn't] touch any other application teams" in light of a security event, he said. 

8. Follow up with location services. 

This step is meant for resilience and disaster recovery. Companies have to create policies designed on a broader scale across location services for day-to-day operations and needs. 

9. Follow up with application services. 

Companies will have multiple application teams sharing resources on a single server, so Mascarenhas suggests avoiding writing policy from the team's perspective. Instead, "write it from the server's perspective," or the database.

Fannie Mae wrote a policy based on what application teams need to connect to a specific database, essentially starting from the end of the line to write policies. 

10. Have a clear understanding of change management. 

Companies need altering mechanisms to call out any changes in processes so teams can categorize what is being deployed.

If change management is done correctly and policy is clearly defined, teams can move their updates into production.