Slashdot Mirror
GOVNET In the Works
gtg010b writes: "According to USA Today, the U.S. government is considering a private network to be used for all government communications. This network would be "separate from the Internet to keep it safe from hackers or terrorists" according to Richard Clarke, the head of the president's "cyberspace security adviser." Whatever happened to government not being above the people?" Clarke is the guy who's been crying "cyber Pearl Harbor" for a few years; apparently if you cry wolf long enough you get promoted. His request (.doc format) is informative. I should point out that the U.S. military already has such a network (I'm not even going to ask why the Feds can't piggy-back on it), so GOVNET would be for critically-important government agencies like the Department of Agriculture to communicate.
People are using the terrorist threat to do things they wanted to do anyway, but would not normally be allowed.
Secrecy and weapons sales corrupt democracy: What should be the Response to Violence?
Bush's education improvements were
Well, considering how many of your tax dollars are wasted when folks hack into their systems and mess them up... Makes sense.
I think this is a great idea. If its thought out well. Heck many large companies do this - you have a set # of firewalsl controlled by ONE group of security professionals. They can link the major sites with some of the tons of dark fiber out there. Smaller sites - use VPN with high encryption over the Internet. That gives you a good cost point since its the small offices that can kill you for an Intranet. Link the large locations with private links. The next step would be to place all their public webservers under the auspices one a single web team to ensure the damn servers are setup properly and securly. But that'll never happen :) Isn't bureaucracy grand? :)
Top Most Bizarre/Disturbing Error Messages
posted without the +1 bonus, so it's easy to ignore:
Request for Information for a Government Network Designed to Serve Critical Government Functions (GOVNET)
1.0 SUBJECT
Request for Information (RFI) for a Government Network designed to provide protected services for critical Government functions. The network is designated GOVNET. Responses are due to this RFI by 4:00 PM on November 21, 2001. See section 8.0 for further information.
2.0 DESCRIPTION
The General Services Administration, at the request of the Executive Office of the President of the United States, and the newly designated Advisor for Cyberspace Security, and in support of National Security goals established by the President, is seeking information from industry that will assist in the development and deployment of a special telecommunications network, GOVNET.
Specifically, this RFI seeks the following information:
Conceptual technical architecture alternatives
Technical feasibility alternatives assessments
Approximate cost information (i.e., order of magnitude, ballpark estimates, etc.) for alternatives
Information about spare or unused telecommunications capacities that could support GOVNET minimizing the need for special construction and associated costs and time delays
Schedule estimates
Ideas and suggestions that provide alternative approaches to designing, developing, acquiring, operating, and managing GOVNET
3.0 REQUIREMENTS
This section enumerates the high-level functional requirements for GOVNET. For purposes of responding to the RFI, requirements in the form of hypothetical locations to be served and associated traffic requirements for initial operational capability (IOC) will be made available to interested respondents at an information exchange meeting (see Section 6.0, below).
GOVNET will be a private Internet Protocol (IP) network shared by government agencies and other authorized users only. GOVNET will provide connectivity among users to a defined set (to be determined) of service delivery points.
There will be no interconnections or gateways to the Internet or other public or private networks. This applies to any network management, control, and maintenance functions for GOVNET as well. Initially, GOVNET will provide private intranet data connectivity within the contiguous 48 United States (CONUS).
GOVNET will provide commercial-grade voice communications capabilities within the network among specified users using the data network components and protocols. Voice services to be supported will include, but not be limited to, conferencing and multicast/broadcast. No connections or gateways to the PSTN or SS7 are envisioned for voice communications.
The potential for adding video communications also exists as a secondary requirement at this time. Video services to be supported will include, but not be limited to, conferencing and multicast/broadcast. As with voice requirements, there will be no communications or gateways outside of GOVNET.
GOVNET will support critical government functions and will be immune from malicious service and/or functional disruptions to which the shared public networks are vulnerable (i.e., so-called cyber attacks). In particular, it shall be impossible for malicious or intentionally disruptive activities (e.g., denial of service attacks) to be perpetrated within GOVNET from any network external to GOVNET. Similarly, it shall be impossible for malicious code (e.g., computer viruses) to penetrate GOVNET from any network external to GOVNET.
GOVNET will provide the highest levels of reliability and availability including trunk and access diversity, and rapid response times for customer outages. This RFI does not specify a particular requirement for availability or reliability. Responses to this RFI will assist in establishing this requirement. In formulating responses, each respondent should describe the reliability and availability characteristics of each alternative included in their response.
GOVNET traffic will be secure (i.e., encrypted by the network using NSA approved encryption techniques), and will be suitable for carrying classified information. For purposes of this RFI respondents should assume encryption of payload data only. No encryption of routing or addressing information is contemplated at this time.
GOVNET will be a turnkey solution offered and priced as a service to participating users. For purposes of this RFI, assume a single invoice with supporting detail presented monthly to GSA will be acceptable.
GOVNET will offer bandwidth-on-demand services at user locations and will be scalable to meet growth in overall network demand and/or peak requirements.
All GOVNET components and links must be located in the U.S. or Canada.
GOVNET shall evolve to maintain technology and service currency with state of the art commercial services to the maximum extent practical.
GOVNET will be operated on a 24/7 basis by the contractor.
GOVNET will provide initial operational capabilities (IOC) within six months from contract award. For purposes of responding to the RFI, IOC is defined as full GOVNET IP connectivity to all locations that will be made available at the public information exchange meeting. Within 12 months after award, voice and video capabilities will be available on GOVNET.
Other requirements not directly related to physical network and services isolation will be addressed at a later date. Examples of such requirements include security policies and security management requirements, required active defense measures, security of network management and control technologies, network capacities, service level agreements, and other important considerations.
The purpose of this RFI is to gather information about those requirements enumerated above. To the extent simplifying assumptions are needed, respondents are encouraged to make and document such assumptions in their responses.
4.0 POSSIBLE NETWORK SOLUTION
GOVNET must meet the functional requirements specified above. The Government is open to alternative concepts for solutions that meet these requirements. The Government encourages creativity and outside the box thinking in responses to this RFI.
One possible solution would be to build a completely dedicated network based on dedicated physical fiber pairs and full path diversity. All hardware would be dedicated, including all transmission equipment, routers, switches, multiplexing equipment, network management and control equipment, etc. In addition, all management and operational personnel would be fully dedicated to the network.
This RFI seeks information about a fully dedicated non-shared network as well as other approaches that could meet the functional requirements with additional levels of sharing of personnel, equipment, and connectivity paths. In doing so, the Government seeks to understand the tradeoffs among risks, costs (initial and ongoing) and alternative technical architectures that incorporate increasing degrees of sharing.
Accordingly, respondents are encouraged to provide information about any alternatives that can be demonstrated to be immune from the kinds of disruptions described in section 3.0, above.
5.0 SAMPLE RESPONSE OUTLINE
Following is a suggested outline and suggested page counts for a response to this RFI. This outline is intended to minimize the effort of the respondent and structure the responses for ease of analysis by the government. Nevertheless, respondents are free to develop their response as they see fit.
Section 1 - Conceptual Alternatives
Briefly describe two or more alternative architecture concepts for GOVNET, including the reliability and availability characteristics of the alternatives. Discuss the capability for the architecture to expand to meet video requirements, and to meet needs outside CONUS. (3-5 pages per alternative with one diagram per alternative identifying the brand/type of equipment that would typically be deployed)
Section 2 - Feasibility Assessment
Briefly describe the feasibility of each alternative and the design tradeoffs involved as matched against the functional requirements and risks of penetration. (1 page per alternative)
Section 3 - Cost and Schedule Estimates
Provide cost estimates for each alternative for 5 and 10-year contract terms for non-recurring and annual recurring costs using the locations provided at the public information exchange meeting(one page table). Also, discuss cost drivers, cost tradeoffs, and schedule considerations (2-3 pages)
Section 4 - Corporate Expertise
Briefly describe your company, your products and services, history, ownership, financial information, and other information you deem relevant. (no suggested page count)
In particular, please describe any projects you have been involved in that are similar in concept to what is described in this RFI, including management and operations approach, security requirements, security assurance processes, and any relevant lessons learned (1-2 pages per project).
Include any comments on the structure of the requirements for a formal RFP response.
Note - please also describe any network capacity assets that you might be willing to dedicate for deploying GOVNET. Examples of such assets might include unsold or unsubscribed capacities, so-called dark fiber routes, assets designated for liquidation or that are financially under-performing, etc.
Section 5 - Additional Materials
Please provide any other materials, suggestions, and discussion you deem appropriate.
6.0 INFORMATION EXCHANGE MEETINGS
GSA and the Special Advisor for Cyberspace Security will hold an information exchange meeting to discuss this RFI with interested potential respondents. Details about this meeting will be made available at a later date. If you wish to attend this meeting, please respond to the contact provided in section 8.0, below.
In addition, GSA will consider meeting individually with interested potential respondents. If you are interested in requesting such a meeting, please respond to the contact provided in section 8.0, below.
7.0 DISCLAIMER
This RFI is issued solely for information and planning purposes only and does not constitute a solicitation. All information received in response to this RFI that is marked Proprietary will be handled accordingly. Responses to the RFI will not be returned. In accordance with FAR 15.202(e), responses to this notice are not an offers and cannot be accepted by the Government to form a binding contract. Responders are solely responsible for all expenses associated with responding to this RFI.
8.0 CONTACT INFORMATION
Following is the Point of Contact (POC) for this RFI, including the public information exchange meeting:
Mr. John (Jack) Braun
(703) 306-6423
jack.braun@gsa.gov
Please submit responses via e-mail in Microsoft Office format by 4:00 PM on November 21, 2001, to the POC at: govnet.ts.fts@gsa.gov. You may also submit supplemental hardcopy materials such as brochures, etc. (5 copies each) to the POC.
Mooniacs for iOS and Android
No, I have worked in corporate IS/IT and here's my experience:
If there is a business need to someone with a leather chair, and a nice enough view...then it will happen. I had to install AOL countless times working in corporate environments (big fun since NT was also the standard and AOL doesn't play nice on NT). Why? Because I wanted to keep my job. "I'm sorry sir, but installing AOL would breach security" is a nice technically sound position, but you need to have someone with the letters "VP" in his title to back that up or the question is "why can't you make it work with AOL and be secure?"
I just think it's impossible to prevent crossovers between GOVNET/Internet because users are going to balk at having two boxes on their desk. Someone, somewhere is going to present a business case for Internet access (how are the GOVNET techies supposed to download drivers unless everything is mirrored internally?) and once that happens I'm positive they won't be smart enough to have an air firewall between them. Multiply that risk by the number of agencies involved and I think the chance of someone making a mistake and leaving a window open are quite good.
Which, again, brings me to my main point...will a separate network make GOVNET security weak? Will they be lazy? Or will they have a properly secured Internet-ready network AND have the separated network security layer to boot?
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
Isn't the ONLY sort of guaranteed security the physical kind? ie: keeping my computer off the internet, and standing next to it with a loaded gun to make sure there is no unauthorised access.
Not Meta-modding due to apathy.
>Why not just encrypt across internet2 or something?
Encryption is still subject to traffic analysis (i.e. monitoring when data moves and where it is going to/from).
Also it may be vunerable to DoS attacks if going across a public network.
> i really don't understand why everyone is crying pearl harbor about everything anyway...
Me neither - I though it was just a knee jerk reaction, but it seems to be persisting.
-- Mike
Believe it or not, I've got a .mil account. Or two, in fact.
for army, in fact - there's an army webmail using certificate based tunneling between the client and server from the us.army.mil server.
*grin* It's a great domain. Haven't seen much spam from it, either.
In the US Air Force, they refer to the internet as NIPRNET (Non-secure IP Router Network). Only unclassified info is sent across it, and sensitive unclassified or privacy act info is restricted to
The other network is called SIPRNET (Secret IP Router Network). On military installations its conduit is encased in concrete, junction boxes are alarmed, & cable drops are only in secure areas. Off the installations it's encrypted. I imagine the encryption is pretty strong since NSA designs the algorithms.
For more info check out these AF regulations:
AFI 33-202: Computer Security
AFMAN 33-221: Computer Security: Protected Distribution Systems (PDS)
AFAIK, banks have a own seperated network.
The DARPA-NET was created to provide a mean to communicate after a nuclear-strike or any other physical attack.
It should be redundant (and by this mean fault tolerant).
Therefor all partners were more or less equal.
It didn't matter which way the packets go and it shouldn't matter.
Security was never a main issue as you can see from the amount of security flaws, which exist(ed) in TCP/IP.
Granted, IPv6 seems to tackle these problems, but it is still not in use. And sometimes it's easier to build something new than to change the existing (I would suggest doing the same with tax law).
What was the best network security tool again? IRC, pliers.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"