Secure Research Lab Network Frequently Asked Questions

About SRLN

What is a Secure Research Lab Network (SRLN)?

A Secure Research Lab Network (SRLN) is a firewalled network designed for hosting machines used in a research lab setting. These machines can be at risk of cybersecurity incidents due to various issues, including:

Running software or an operating system that cannot be upgraded.
Managing unprotected network services that put data at risk.
Hardware that does not support full-disk encryption.
Not meeting Stanford's other Device Compliance requirements.

We recognize that equipment and instrument manufacturers are responsible for configuring their hardware and software. An SRLN provides an alternative to meeting Stanford Device Compliance. The target audience for an SRLN is labs and service centers (also called "core facilities" or "cores"). Each SRLN has a single "owning group", with all machines on that SRLN owned and/or managed by that group.

The target audience for an SRLN is labs and service centers (also called "core facilities" or "cores"). Each SRLN has a single "owning group", with all machines on that SRLN owned and/or managed by that group.

What types of machines should not be connected to the Secure Research Lab Network (SRLN)?

The SRLN is not meant for machines that meet Stanford's Compliance requirements. For example, the SRLN is not intended for your Stanford-issued laptop or server.

How does a Secure Research Lab Network differ from a typical building network?

There are several major differences:

Dedicated network for your group: This network is specifically created for your group's endpoints that need to be connected but cannot meet Stanford's Device Compliance requirements, even if your group occupies most of a building's network.
Locked-down defaults: Unlike typical firewalled building networks that allow outbound access by default, Secure Research Lab Networks do not. The distinction between SRLN and standard departmental firewall projects is that while departmental projects restrict inbound connections but allow unrestricted outbound connections, SRLN projects restrict both inbound and outbound connections.
Ease of management: The goal is to make the Secure Research Lab Network as easy to manage, if not easier, than a firewall network.

How does a Secure Research Lab Network differ from the Winsecure networks?

The Secure Research Lab Network is similar to Winsecure — they both serve the same purpose, but there are several differences:

Your Secure Research Lab Network is its own subnet/VLAN/firewall zone: Winsecure networks are multiple subnets that share the same VLAN and firewall zone.
You have ultimate control over the firewall rules: Instead of routing changes through one group, you (or your LNA) are responsible for approving rule changes.

Who will be managing the network?

Your Local Network Administrator (LNA) will manage the Secure Research Lab Network.

What is an LNA?

A LNA (Local Network Administrator) is a person or group that serves as your primary contact for all matters related to the Stanford University Network (SUNet). This includes connecting machines to the network and modifying firewall rules. Your LNA may have additional computer-related support roles. Your LNA plays an integral part in the migration to the Stanford Research Lab Network.

Who is my group's LNA?

Not sure who your LNA is? View the LNA by Department web resource to learn more. If you recognize a person or group on your department's list, that person or group might be your LNA.

Please confirm with your LNA that they are the appropriate administrator for setting up a Secure Research Lab Network. For example, if you are a service center in a School of Engineering building, SoE IT may provide support as a courtesy, but they might not be your official LNA.

If your group does not have an LNA, we recommend contracting with CRC Research Lab Support. This team provides IT support for research endpoints and is very familiar with the SRLN migration process. This is a paid support service; the scope of work and associated costs will be determined during the consultation process and provided for your agreement.

Can I turn an existing network into a Secure Research Lab Network?

There are several factors which can prevent the conversion of an existing network into a Secure Research Lab Network.

Secure Research Lab Networks are meant for non-compliant devices only. If your existing network has a substantial number of compliant devices, it is better to move the non-compliant devices into a new network.This helps isolate them from other, compliant devices.

Secure Research Lab Networks block all inbound and outbound traffic by default. Compliant devices on an existing network might not be prepared for such a block.

Secure Research Lab Networks have specific naming standards for their Netdocs projects and zones. They also include numerous rules for implementing the Menu. Implementing those changes will disrupt devices on your existing network.

Finally, we want your Secure Research Lab Network to start out with a "clean slate". Migrating an existing network would require auditing existing rules, deleting old rules, and potentially breaking connectivity for machines that do not need to migrate. Starting fresh means you can leave existing firewall rules alone and test (and migrate) machines as slowly as needed to minimize outages.

If you are interested in migrating an existing network to the Secure Research Lab Network, schedule a consultation.

Can I use a Secure Research Lab Network with High Risk data?

Possibly! Networks used for high-risk data (PHI and non-PHI) often resemble Secure Research Lab Networks in that inbound and outbound access are tightly controlled.

We recommend contacting the Information Security Office (ISO) (or, for the School of Medicine, TDS Information Security Services) as soon as you know that you will need to use a non-compliant device with high-risk data. If you have an existing DRA, you should raise the issue there; otherwise, open a MinSec Temporary Exception Request HelpSU.

I'm interested in moving my lab to the Secure Network. How do I get started?

To get started, explore the "Get Started" section of the Secure Research Lab Network service homepage.

How does the migration work?

The migration begins by requesting a Secure Research Lab Network consultation with UIT Networking. The consultation provides a review of the entire migration process and offers an opportunity to answer your questions.

During the consultation, you will be given two items — a document and a spreadsheet — to complete. The spreadsheet will ask for detailed information about the machines that will be migrating; the document will contain summary information based on the spreadsheet's contents.

Once the document and spreadsheet are ready and you want to continue with the migration, you will need to submit a New Secure Research Lab Network request. That will prompt UIT Networking to create your new firewalled network and make ISO aware of your migration. Once UIT Networking has created your network, they will contact you.

After that, the migration is up to you! You will be responsible for scheduling and implementing the migration for each machine. The HelpSU request that you opened to start the migration will remain open until the migration is complete. You can use the request to send questions to UIT Networking and to notify ISO when the migration is complete. Once the migration is complete, ISO will update the compliance-exception records to reflect the five-year expiration.

Once the migration is complete, ISO will update the compliance-exception records to reflect the five-year expiration.

Can I add machines to a Secure Research Lab Network after the initial migration?

Yes! To migrate an existing machine to an existing Secure Research Lab Network, you should perform the same actions that you performed during the initial migration:

Identify what firewall rules are needed for the machine
Allocate an SRLN IP for the machine
Submit firewall rule requests
Migrate the machine

If you are purchasing a new machine that will need to be on an SRLN, consider connecting it to the normal building network first. You will have 30 days to complete the migration process.

Can I move a Secure Research Lab Network machine to another location?

Yes! Contact your LNA before the move takes place. They will help prepare a TSO port at the new location.

Can I give a Secure Research Lab Network machine to another group?

Yes! Before you give away the machine, contact your LNA. Your LNA will delete any custom firewall rules for the machine, delete the machine's SRLN IP address, and will submit a Help request to notify ISO about the move.

The other group can choose to operate the machine not on the Stanford network, add it to their own SRLN, or obtain normal one-year compliance exceptions.

Finally, if the machine has a Stanford asset tag, the capital asset's record will need to be updated. For more information, see the Purchase and Manage Capital Equipment topic on Fingate.

Network

Do I need to purchase or rent switches? Will construction be required?

Most likely, you will not need to purchase or rent switches or undertake construction — the Secure Research Lab Network uses the same University IT-managed switches and Telecommunications Service Outlets (TSOs) as a normal building network. However, some campus buildings have local IT contacts who manage the network switches. In these cases, your local IT contact will need to be involved in the planning and migration process.

Generally, we prefer that machines be connected directly to a TSO rather than to an intermediate switch (such as an unmanaged switch on a floor or bench). This makes management easier and allows for a smoother migration. If you do not have enough TSOs in your space, please mention this during your consultation meeting.

Some of the ports on my TSOs do not work. Can you help?

Chances are, those ports are not connected to a network switch ("patched"). Your LNA can help make those connections. If you do not know your LNA, or still need help, you can submit a Help request to the Net-To-Jack team to get a TSO connected.

How can I switch a network jack from a building network to a Secure Research Lab Network?

For University IT-managed switches, LNAs will have access to a website — the VLAN Change Tool — which can be used to change a switch port's VLAN. As part of the process for creating a new SRLN, we ensure all the involved LNAs have access to the VLAN Change Tool.

When I change VLANs, do I need to make any changes on my machines?

Yes! Your machines' Ethernet connection will need to be configured to "automatic (DHCP)" (on Windows) or "using DHCP" (on macOS).

Since the VLAN Change Tool does not shut down a switch port, you will need to instruct your machine to stop and restart its physical network connection.

The easiest way to do this is to unplug the Ethernet cable from your machine.

If you cannot access the back of the machine, you can unplug the Ethernet cable from the wall jack. Once unplugged, wait ten seconds, then plug the cable back in. Your computer should pick up the new IP address. If you cannot get access to the TR, you may be able to perform a DHCP "release and renew." Some non-Stanford guides include:

Finally, if all else fails, try restarting the machine.

How large will my Secure Research Lab Network be?

As large as you need! In general, the network size is determined by following this algorithm:

Once the inventory of machines is complete, count the number of machines; then
Ask the lab manager (or other appropriate person) about any planned purchases; then
Add three (to account for the IP addresses used by the network); finally
Round up to the nearest power of 2.

Total # of Machines = (# of Machines in Inventory + # of Planned Purchases + 3), rounded up to the nearest power of 2.

Will my machines have access to the Internet?

Yes! A typical Secure Research Lab Network operates as a 'shady network.' In this setup, machines can access the internet via the campus Network Address Translation (NAT), enabling machines to share a single public IP address. However, while shady network machines can receive connections from users on the campus network or those connected through VPN, they do not allow incoming connections from external sources on the internet.

It's important to note that even though an SRLN is classified as a shady network, machines won't have immediate access to the internet. By default, the firewall restricts most inbound and outbound connections, permitting access only to services included in the default ruleset or those you request through the Menu items. Any additional access — whether inbound or outbound — must be requested through firewall rule requests or Menu requests.

Will my machines have access from the internet? Can I have public IPs?

If you have a demonstrated need, then yes! Generally, this is used in situations where machines need to accept unsolicited inbound connections from folks who do not have SUNetIDs and who cannot use the VPN.

If your machines are using programs like Bomgar, RemotePC, or TeamViewer, those programs initiate connections to the outside world and do not need public IPs. If your machines use RDP and RDP connections are made by folks with a SUNetID, then SUNAC can be used instead of public IPs.

If your machines need to accept connections from Stanford AWS accounts or Stanford Google Cloud projects, University IT's Cloud Gateway service is an alternative to public IP addresses.

Giving non-compliant machines access to the internet is very risky, so you will be expected to take extensive measures to protect your machine. ISO is available to help, but ultimately, the decision about whether to use public IP addresses is up to you. If you need to contact ISO, please submit a Help request.

Can I have multiple Secure Research Lab Networks?

Generally, each group is allocated one Secure Research Lab Network, which is a shady network. But there are situations in which a single group may have multiple Secure Research Lab Networks.

For example, a service center might present a single "public face" to customers, but be implemented as multiple self-contained groups behind the scenes. In a situation like this, it would be appropriate for each group to have its own Secure Research Lab Network.

In another example, a group might have some machines used to acquire identifiable data (for example, metadata containing a human's name and date of birth), and others used to acquire anonymous data that cannot be identified. It may be appropriate to have separate Secure Research Lab Networks for machines with different Risk Classifications.

My machines are spread across multiple buildings. Can I still have one Secure Research Lab Network?

Yes! The current generation of the Stanford University Network (SUNet) supports VLANs spanning multiple buildings on campus. Additionally, it's possible to have a VLAN present in both a main campus building, a Stanford Research Park building, and a Stanford Redwood City building. Please note: all buildings must be SUNet-connected buildings. Hospital buildings, the VA, and more remote locations (like Hopkins Marine Station) might not support SRLN VLANs.

One question asked before an SRLN is created is "What buildings should this network be in?" We use this question to ensure the new network is available in all your buildings.

Can I add wireless devices?

The Secure Research Lab Network is designed for wired devices only, but a workaround may be available. When you reach out for a consultation meeting, be sure to bring this up! Be prepared with the following information:

Do the wireless devices support DHCP?
Do the wireless devices support WPA2 or WPA3, or an older encryption standard (like WPA or WEP), or nothing at all?
What is the latest WiFi version that the devices support?

How will network changes work?

Although a Secure Research Lab Network is a specialized network, network changes are done the same way as a building network: Your LNA is given access to allocate SRLN IP addresses in NetDB and will initiate tasks like network expansion (to support more devices) or making the network available in new buildings.

How do I get a new VLAN added to a switch?

Please submit a Help request, and include the Secure Research Lab Network VLAN number, and the names of the switches where you want the VLAN made available.

If you do not know the switch names, you can find them at the TR (the network closet) for your area. If you are unable to access the TR, you should say so in your Help request and provide your building name or number. Networking will help identify the correct switches.

I do not have access to change NetDB. Can you help?

For all NetDB assistance, please submit a Help request.

To change a NetDB record, you need to be a member of a NetDB Group that is attached to the Node. In your Help request, provide the NetDB Node name and the name of the NetDB Group that should be added to the Node.

If you are not part of a NetDB Group, someone already in the Group should submit a Help request to have you added to the Group. If you do not have access to NetDB, that same person should also ask that a NetDB account be created for you.

I do not have access to the VLAN Change Tool. Or I have access, but cannot change VLANs. Can you help?

First, verify that your colleagues do not have access and cannot grant you access via workgroup membership. If they are unable to grant you access, or if you have access but cannot make changes, please submit a Net-to-Switch Help request. In order to fully use the VLAN Change Tool, you need to be granted access in two places:

The VLAN Change Tool's website: access is granted via the Workgroup Manager.
Control over a particular switch: once you have access to the tool's website, you must be given access to a NetDB Group.

Note: In your Net-to-Switch Help request, please provide the switch names and the NetDB Group that should have access to them. If you have access to the switch, but cannot see your new VLAN, it might not be active on the switch. See "How do I get a new VLAN added to a switch?" for more information.

Firewall

How can I see my network's firewall rules?

Your Secure Research Lab Network will get its own Netdocs project. Your project's name will start with the word "SecureNet."

If you still cannot see your Netdocs project, talk to your LNA.

Can I see the rules for other Secure Research Lab Networks?

Yes! Netdocs has a single-page list of rules which apply to all Secure Research Lab Network zones. However, you might not be able to see rules for other zones if you lack the necessary workgroup membership. If you think you are missing something, talk to your LNA.

I am seeing lots of firewall rules that I did not request. What are those for?

In addition to the rules you have requested, your Secure Research Lab Network zone will contain a copy of the default ruleset. You might also see a number of disabled rules, which represent Menu items that you could request in the future. Finally, each zone will have a rule at the end of the outbound rules that blocks unpermitted outbound traffic.

Some rules have text in the Auth column. What is that?

If a rule in Netdocs has text in the Auth column, that means the rule has a SUNAC workgroup attached to it. The rule will only apply to users who are in the named workgroup and who are using SUNAC.

What is SUNAC?

Network Access Control (SUNAC) is a capability unique to Stanford firewalls. It allows you to limit a firewall rule to specific people based on their membership in a workgroup.

Every Secure Research Lab Network includes a workgroup that can be used for SUNAC-enabled firewall rules in your zone. When you order items from the Menu — such as Remote Desktop Protocol (RDP) — those items will have your SRLN SUNAC workgroup attached to the firewall rule.

How do users use SUNAC?

Users use SUNAC by being members in a workgroup, and then connecting one of two ways to the Stanford University network:

Via VPN from any location
When on campus, using the eduroam Wi-Fi network, with a compliant machine (that is, a machine which appears in MyDevices)

How can I make firewall changes?

Secure Research Lab Network firewall zones use the same Netdocs tools as other firewall zones, but some of the special SRLN-specific features are only available if you know how to request them.

Rules in the default ruleset cannot be changed. Rules ordered from the Menu can be ordered using the Netdocs request form. See the "Default Rules & the Menu" section for more information.

For other rules, you should use the same process that you would normally use for adding and changing firewall rules. If you are planning on making a new inbound rule, consider using SUNAC. See "What is SUNAC?" for more information.

How can I allow access to a website?

Firewall rules are normally limited to IP addresses, but Secure Research Lab Network firewall zones can have rules that provide access to specific websites. This is useful, because most websites (especially cloud-based websites) do not have a dedicated IP address.

Before requesting access to a website, you should check if you will also need access to other, 'supporting' websites. For example, iLab uses Google Fonts, so if you wanted to provide access to iLab, you would also have to provide access to Google Fonts.

Once you have the list of websites you want to access, use the Netdocs self-service automation tool, like you would for other requests. Look for the option to "Request something else for this project"; in the details of your request, provide the list of web sites that you would like to access.

Default rules and the "Menu"

What is the default ruleset?

The default ruleset is the set of firewall rules that are applied to every Secure Research Lab Network. The SRLN default ruleset is different from a "typical" firewall's default ruleset.

View the default rules on the Secure Research Lab Network "Menu" of Available Services webpage.

What is the Menu?

The Menu is a collection of pre-made firewall rules for services used by Secure Research Lab Network users. Instead of figuring out what to request, LNAs can simply "order off the menu", knowing that the firewall rules will work right the first time.

Learn more about the Menu on the Secure Research Lab Network "Menu" of Available Services webpage.

How do I order from the Menu?

You can find instructions on the Secure Research Lab Network "Menu" of Available Services webpage.

How are Menu items added? Can I get something added?

The Menu contains services that would be of interest to multiple groups. For example, multiple groups use RDP to connect to their machines, so that is a Menu item.

If you have an item that you think would be good to add as a Menu item, the first step is to add it as a firewall rule for your own SRLN firewall zone, using the Netdocs self-service automation tool. If you know of another group that has a firewall rule that you want, you can use the "Request something else for this project" to ask for their rule to be copied to your firewall zone.

The UIT firewall engineers implement all new rules. When they see multiple groups requesting the same rule, they will consider it for adding to the Menu.

How are the default rules chosen? Can I get something added?

The default ruleset contains services and websites that meet two criteria:

Many groups need this. Besides services like DHCP and DNS (which machines need), this for example, includes iLab (which many service center techs need).
ISO has decided that "lateral movement" by a malicious actor would be difficult. This is why Google Drive is not in the default ruleset, as it is relatively easy to exfiltrate data using Google Drive.

If you think something should be added to the default rules, the first step is to get it added as a new Menu item. Once it becomes a Menu item, submit a MinSec Temporary Exception Request HelpSU, giving the name of the Menu item and an explanation of why it should be added to the default rules.

Security and compliance

When will MyDevices show a device to be exempt from compliance enforcement?

After 24 hours, once ISO has implemented the compliance exception.

As part of the migration process, a Help request will be used for communications between you, ISO, and Networking. Whenever you complete migration for a device, you should notify ISO using the Help request. ISO will then update compliance records for the device, and notify you that this has been done.

If 24 hours have passed since ISO's notification that the compliance exception is in place, the compliance exception might be associated with someone else. Use the Help request to ask if this is the case.

Will I still need to renew compliance exceptions every year?

ISO will still require renewing compliance exceptions. Exceptions will need to be renewed every 5 years, instead of every year.

The primary reason for this is lifecycle management, ensuring that decommissioned machines have their NetDB Nodes, firewall rules, etc. cleaned up. For machines that move into a SRLN after its creation, ISO may assign a shorter compliance-exception period.

The reason behind this is to have all of a lab's compliance exceptions expire around the same time.

What about machines that move into the SRLN after the network's initial creation?

For machines moving into the SRLN after the initial migration, you should notify ISO about the migration using the MinSec Temporary Exception Request HelpSU. You should submit the HelpSU only after the machine's NetDB Node has been reviewed, and after the NetDB Node has had a SRLN IP address assigned.

In the Help request form, provide the machine's MAC address, so that ISO can find the machine in NetDB and in their records.

I have a machine on a private (non-SUNet) network. Can I move it to a SRLN without it becoming non-compliant?

Yes. If a machine does not have a NetDB record, then from the SUNet perspective, this machine is a new machine. New machines have 30 days to either become compliant or get an exception. So, you will have several weeks to:

Create a NetDB Node for the machine, with a SRLN IP address; and then
Use the compliance exception process to notify ISO about the migration to the SRLN.

If you have not started the migration process, you should request a normal compliance exception. That will give you up to one year to go through the migration process.

If this is your initial migration, you should use your migration Help request to notify ISO. If you are adding this device to an existing SRLN, you can notify ISO — and request a SRLN exception — using the MinSec Temporary Exception Request HelpSU.

I have a machine that is currently compliant, but will become non-compliant soon. Can I get an exception now?

If a machine is already on the Stanford Network, then if MyDevices detects that it is non-compliant, you will have 30 days to get the device into a SRLN and notify ISO. If you have not started the migration process, you should request a normal compliance exception. That will give you up to one year to go through the migration process.

If you have started the migration process, or you are moving the device to an existing SRLN, you should take the following actions now:

Ensure the device's NetDB Node is accurate.
Add a SRLN IP address to the device's NetDB Node.
Notify ISO, that the device will become non-compliant soon.

To ensure the device actually moves to a SRLN, ISO may provide a short-term compliance exception. If they do that, ISO will let you know, and you should let ISO know once the device moves, so they can extend the compliance exception to a full five-year exception.

Will I be notified when my 5-year compliance exception is due for renewal?

Yes, as long as MyDevices believes that you are the primary user of the machine. In other words, if you go to MyDevices and see the machine in your list of devices, then you should expect to receive an email 30 days before the 5-year compliance exception expires.

If you do not see the machine when you go to MyDevices, you will need to tell ISO, so they can update their compliance-exception records. You can notify ISO via the MinSec Temporary Exception Request HelpSU. In the HelpSU, provide the machine's MAC address, so that ISO can find the machine in NetDB and in their records.

Can I exclude my machines from Windows Updates?

We understand that some machines, particularly those with a vendor or regulatory certification, may only receive operating system updates that have been authorized by the vendor. Although there are methods to control Microsoft Update (which provides updates for Windows and other Microsoft products), we recognize that Microsoft has ignored or overridden those preferences in the past.

The default ruleset for Secure Research Lab Networks does not include Microsoft Update servers, so SRLN machines are blocked from Windows updates by default. However, "Microsoft Windows Update" is available as a Menu item, for those who want continued access to Microsoft updates.

We recommend that machines continue to receive Windows updates if possible, especially machines running Windows 10. From time to time, Microsoft has been known to release updates for their operating systems that have passed their End of Life date.

Can I exclude my machines from BigFix or CrowdStrike?

The default ruleset for Secure Research Lab Networks includes rules that allow access to the BigFix for Endpoints and BigFix for Servers environments, as well as to CrowdStrike.

BigFix and CrowdStrike only work if the appropriate client is installed on the managed machines. If you have a machine that you do not want to access BigFix (or CrowdStrike), you should uninstall the BigFix (or CrowdStrike) client from your machine. If you are not sure how to do that, talk to your local IT support contact.

Can I exclude my machines from Qualys scanning?

Qualys scans take place across the entire Stanford University network (SUNet), with machines being scanned regularly by ISO. Additional scans may be performed by your School or Department IT, and they or ISO may perform one-off scans to identify "zero day" vulnerabilities that may be active on SUNet. As Secure Research Lab Networks are part of SUNet, they go through the same scans.

We understand that Qualys scanning can cause issues for machines. If your machines are already on SUNet, then they are being scanned today. Moving to a SRLN will not increase the intensity of those scans. In some cases, ISO applies a "lite" configuration to certain devices, reducing the intensity of scans.

If this is your initial migration, you can if you wish use your migration Help request to ask ISO for this "lite" configuration. If you are adding this device to an existing SRLN, you can notify ISO—and request a SRLN exception—by submitting a Vulnerability Scanning (Qualys) help request.

Can I continue to use a web browser?

Internet Explorer — the browser shipped with Windows 7 & Windows 8 — is not being updated. Most websites will not work with Internet Explorer.

For a modern browser that works on Windows 7, 8, and 10, we recommend using Mozilla Firefox ESR (Extended Support Release). The Mozilla download site still works with Internet Explorer, so you can use Internet Explorer to download Firefox ESR.