10 Steps for A Military SharePoint Contract

Recently a friend of mine won a substantial SharePoint military contract which I contributed to the RFP for since I owed him a favor (your welcome Kirk for my entire weekend). Although he has been doing SharePoint since it was Tahoe, he had on no account held a military contract, and was wondering about some pointers that he could take in that would facilitate reduced resistance, and increased applicability while engaging on the SharePoint project. As a result I started writing a personal email to him regarding some concepts since I just moved back into the private sector so felt equipped to, which hurriedly I could see as being a constructive post so determined to put it out there for the community.

Now this is all subjective, and might not translate to all military SharePoint contracts, so take it with a grain of salt. Though I think that bulk of the points are generalized enough that it should at least provide reasonable applicability for a preponderance of military contracts, matters such as these should be looked with gargantuan scrutiny.

Military Personnel Cause More Friction Than Private Markets

This really took me a while to get used to in view of the fact that for an assortment of private SharePoint projects it can be recurrent that people are in reality eager for a SharePoint deployment. Because of the way indirect clout and influence is shared within an orthodox military structure, and while there certainly is a defined chain of command, the defined rigidity does not make it an absolute. There might be a GS 9 through 11 that has been entrenched in a unit waiting on their pension, and they are a hard sell because they have been doing things a particular way for nearly 20 years. It has worked thus far so why change it now? And while on paper the persons ranking might not be directly impressive, that person’s relationships should make you look at them like they are a SES 2 as far as you are concerned. More often than not, you can gauge the assimilation of your deployment by measuring the adaptation of the product by such people, not by the early adopters that are clearly biting at the chomp in order to leverage SharePoint. Understanding these unspoken and undocumented relationships is huge!

It is important to realize that there is a huge gap between the private sector and the military segment in this regard. In the military, you would actually think that rank is king and that is the end of it. However it is customary that relationships habitually will trump rank. Furthermore, in the military, product use can, and more often than not, will be forced by a commander if you don’t play the implementation role just right. While this seems like it would be a benefit, you will quickly find out that it is the quite opposite. The old mantra You can catch more flies with honey than with vinegar goes right out the window, and now you are not the most favorite person in your unit since you are forcing people to change the way they do their jobs. Not only is this bad for the current state of your contract and your user audience, wait until the contract is up for rebid and those identical people are solicited for feedback during the proposal lobbying.

You Are Not A Civil Service Employee. You Are A Contractor

Don’t portray yourself as being a civil service employee regardless of where you are, it is a terrible habit to get into it and can be misconstrued as offensive to civilians. Most civilians have influential reasons for being a civilian otherwise they WOULD be contractors. The line between a civilian and a contractor is NOT fine, nor should it be or ever considered to be. You don’t walk into a meeting at a private sector client and claim that you work directly for the company in some position that would clearly only exist as an FTE at a private sector firm, don’t do it in a military environment.

FFS Don’t Piss Of IA

As far as you should be concerned, IA is trump. Not only should you not cause problems with them, making a good friend in IA will span your bases and contracts. I have known my same IA contact for nearly 5 years now, and even though he is staffed permanently at a different base I will most likely never work at again, the information he gives me regarding any of my current and future contracts regardless of station is nothing less than priceless. Just don’t do things that knowingly are going to make them upset, like putting a NIPR and SIPR box within the physical proximity limits of each other. They will rip your head off, and then you are on their radar and you will get hit on each audit. It’s kind of like the IRS in that sense I suppose.

Hiring A Generic Project Manager Will Go Over Like A Fart In Church

If you are responsible for staffing, do not under any circumstances hire a generic project manager for a military SharePoint contract. A project manager in a military environment is a specialized position since they have to understand the inner working of the military, this type of knowledge is disseminated through experience and not through book smarts or nonspecific PM knowledge. While a generic PM might understand the fundamental ranking and command hierarchy concepts, they will have no clue about how the military cogs make the overall federal machine work. Unless you want to send a lamb to the slaughter, just avoid it and shell out the money for a PM either with direct military background or previous federal work history (state governments generally do not count). Going back to the above point about acclimation of product, the PM will heavily be responsible for facilitating the rely of operational information that will affect the whole project. When they get the aggregate picture along with the intricate unit workings, their contributions are unmistakably noticeable and will cause the project to run much smoother.

Don’t DARE Tell A Commander How To Run His Unit

I love it when I am in a meeting and I see someone do this. A commander didn’t get to his position because he took shit on a daily basis from contractors telling him how to do things; they are in a leadership position because they are leaders and were noticed as such. They know their unit; otherwise they wouldn’t be in command of it. Don’t try to tailor a unit to SharePoint, simply give a commander options, and believe me, he will tell you exactly how he wants SharePoint to run in his unit. Trying to tailor a process to a product is poor form anyways; a military environment is unquestionably no exception. The best mantra when working with a commander is take ever should you were about to say and switch it with a could. There are many neat portions of SharePoint that could potentially solve critical business issues; they just need to be presented delicately and with tact.

What The…Different Commander, Different Day

It is pretty recurrent that command changes ensue, at least it was in the Air Force it is habitual. Don’t let it dishearten you; unless it results in the project getting canned then I would be frustrated as well. Restructuring is incomparably common in the military because the pronouncement can come from so many directions and sources, and while some are based on timely rotations, others are to optimize the workings of the unit(s) (such as unit merges, etc.). If you substitute commanders, you must approach the new commander and show him the value in your work instantaneously. The same reasons that the old commander firstly solicited you as a contractor for must be presented to the new commander so that he can see the significance in your work since he will be unacquainted with preceding efforts. If it is not immediate, manufacture a practical case study because it is worth the time. Otherwise, there is regularly a budgetary review process as one of the first things on a new commanders list, and he/she won’t even know why that money is going to a particular project.

Use That One Guy That Has Been On A Military Contract

I can’t emphasis this enough, on most military SharePoint projects this is generally one person on the team that has already done an enterprise SharePoint deployment in a federal environment. Same branch? Tremendous! Different Branch? Not as great, notwithstanding still pretty damn good. And it might not even be the person that is judged to be the most indispensable personnel on your team. Their insight into the pre-workings of a military structure you will discover to repeatedly save your ass again and again. Even when those concepts aren’t related to your SharePoint deployment and are just insights into significant military processes.

Acronyms Are Better Than No Acronyms

There are so many acronyms. There are acronyms for things that shouldn’t even be acronyms, but because it is an unspoken tradition to turn any three letter denotation into an acronym, you really have to get used to it. And seriously, don’t bother writing them down since there will be repetition in the acronyms that are used. You will end up using the same acronym a lot, but based on the context, it will have severely dissimilar meanings. This must be taken into account for particular audiences and will lessen confusion.

Military Liaisons Are Worth The Money

Especially if they were stationed at the base your contract is at, even better if they were in the same unit and command hasn’t changed. That comradery is invaluable and the preexisting relationships will make your life infinitely easier. They do cost a lot of money, and normally their solitary deliverables are esoteric, however the difference is directly noticeable.

You Are Contributing Most Likely to a War Effort, Not a Random Business

Within a military contract the work that you are doing has severe impacts that are by and large not found in the private sector. Sure, there are definitely outages which effect private business and that is no good; however they don’t affect people in the field that are relying on your system for war support. Most developers for example will recycle an App Pool to realize a new GAC versioned assembly being deployed and not bat an eyelash. Taking this mindset into a military environment will make your SharePoint contract the quickest one in federal history. Those actions ARE noticed, ARE logged, and will be examined. People will notice that brief latency shift, and you can bet your ass that you will hear about it later.

There are so many more, but that’s about it for now! Happy military SharePoint contracting!

Share

SharePoint Virus Detection Policy Template

This file was edited for correctness by Edgardo Gonzalez of PRSL.

Introduction – SharePoint Virus Policy Template The number of SharePoint security incidents and the resulting cost of business disruption and service restoration continues to escalate. Implementing solid SharePoint security policies, blocking unnecessary access to networks and computers, improving user security awareness, and early detection and mitigation of security incidents are some of the actions that can be taken to reduce the risk and drive down the cost of SharePoint security incidents.
Purpose The purpose of the [Organization] SharePoint Virus Policy is to to describe the requirements for dealing with computer virus, worm and Trojan Horse prevention, detection and cleanup.
Audience The [Organization] SharePoint Virus Policy applies equally to all individuals who use any [Organization] SharePoint resource.
SharePoint Virus Policy Definitions
  • Virus: A program that attaches itself to an executable file or vulnerable application and delivers a payload that ranges from annoying to extremely destructive. A file virus executes when an infected file is accessed. A macro virus infects the executable code embedded in Microsoft Office programs that allows users to generate macros.
  • Trojan Horse: Destructive programs-usually viruses or worms-that are hidden in an attractive or innocent-looking piece of software, such as a game or graphics program. Victims may receive a Trojan horse program by e-mail or on a diskette, often from another unknowing victim, or may be urged to download a file from a Web site or bulletin board.
  • Worm: A program that makes copies of itself elsewhere in a computing system. These copies may be created on the same computer or may be sent over networks to other computers. The first use of the term described a program that copied itself benignly around a network, using otherwise-unused resources on networked machines to perform distributed computation. Some worms are security threats, using networks to spread themselves against the wishes of the system owners and disrupting networks by overloading them. A worm is imilar to a virus in that it makes copies of itself, but different in that it need not attach to particular files or sectors at all.
SharePoint Virus Policy
  • All workstations whether connected to the [Organization] SharePoint network, or standalone, must use the [Organization] approved virus protection software and configuration.
  • The virus protection software must not be disabled or bypassed.
  • The settings for the virus protection software must not be altered in a manner that will reduce the effectiveness of the software.
  • The automatic update frequency of the virus protection software must not be altered to reduce the frequency of updates.
  • Each file server attached to the [Organization] network must utilize [Organization] approved virus protection software and setup to detect and clean viruses that may infect file shares. It must be appropriately audited to ensure that viruses have no means to channel into SharePoint.
  • Each Exchange gateway must utilize [Organization] approved e-mail virus protection software and must adhere to the IS rules for the setup and use of this software.
  • Every virus that is not automatically cleaned by the virus protection software constitutes a security incident and must be reported to the [Organization] Help Desk.
SharePoint Portal Password Policy Supporting Information
  • Any and all [Organization] SharePoint security controls must not be bypassed or disabled.
  • All [Organization] SharePoint users are responsible for managing their use of SharePoint and are accountable for their actions relating to SharePoint security. Users are also equally responsible for reporting any suspected or confirmed violations of this policy to the appropriate management responsible for SharePoint security incident handling.
  • The use of SharePoint must be for officially authorized business purposes only. There is no guarantee of personal privacy or access to tools such as, but not limited to; SharePoint areas, WSS team sites, any and all collaboration and communication functionality, and any sister sever integrations (i.e. integrated Microsoft Exchange environments). The use of Sharepoint and SharePoint related tools may be monitored to fulfill complaint or investigation requirements, including forensic an analysis into IDS or other security systems. Departments responsible for custody and operations of the SharePoint servers (custodian departments) shall be responsible for proper authorization of SharePoint server utilization, the establishment of effective use, and reporting of performance to management.
  • Any data housed within SharePoint must be kept confidential and secure by the respectful [Organization] SharePoint user. The fact that the business data may be stored electronically (i.e. document library or SharePoint list) does not change the requirement to keep the information confidential and secure. The type of information or the information itself is the basis for determining whether the data must be kept confidential and secure. Furthermore if this data is stored in a paper or electronic format, or if the data is copied, printed, or electronically transmitted the data must still be protected as confidential and secured.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All commercial SharePoint software used in [Organization]’s SharePoint environment (i.e. Web Parts) must be supported by a software license agreement that specifically describes the usage rights and restrictions of the product. SharePoint users must abide by all license agreements and must not illegally copy licensed software. [Organization] reserves the right to remove any unlicensed software from the SharePoint environment.
  • [Organization] reserves the right to remove any non-business related SharePoint software or files from the SharePoint environment.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share

SharePoint Incident Management Policy Template

Introduction – SharePoint Incident Management Policy The number of SharePoint security incidents and the resulting cost of business disruption and service restoration continue to escalate. Implementing solid SharePoint security policies, blocking unnecessary access to networks and computers, improving [Organization] user security awareness, and early detection and mitigation of security incidents are some the actions that can be taken to reduce the risk and drive down the cost of security incidents.
Purpose This [Organization] SharePoint Incident Management Policy describes the requirements for dealing with SharePoint security incidents. SharePoint security incidents include, but are not limited to: virus, worm, and Trojan horse detection, unauthorized use of computer accounts and SharePoint systems, as well as complaints of improper use of SharePoint resources.
Audience The [Organization] SharePoint Incident Management Policy applies equally to all individuals that use any [Organization] SharePoint resources.
SharePoint Incident Management Policy
  • [Organization] [every organization should have a committee to handle security incidents, enter that name here] members have pre-defined roles and responsibilities which can take priority over normal duties.
  • Whenever a SharePoint security incident occurs, such as a virus, worm, hoax email, discovery of hacking tools, altered data, etc. is suspected or confirmed, the appropriate, documented SharePoint incident management procedures must be followed.
  • The [Organization] SharePoint administratior and user community is responsible for notifying the [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] whom initiates the appropriate incident management action including restoration as defined by [SharePoint Portal Owning Organization / Incident Handling Unit labeled above].
  • The [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] is responsible for determining the physical and electronic evidence to be gathered as part of the Incident Investigation. This can involve the investigation of several servers, including the ISA or other machines in between the client and afflicted system.
  • The appropriate SharePoint and Systems Technical Resources from the [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] are responsible for monitoring that any damage from a security incident is repaired or mitigated and that the vulnerability is eliminated or minimized where possible.
  • The [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] will determine if a widespread [Organization] communication is required, the content of the communication, and how best to distribute the communication.
  • The appropriate technical resources from the [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] are responsible for communicating new issues or vulnerabilities to Microsoft (SharePoint vendor) and working with the vendor to eliminate or mitigate the vulnerability.
  • The [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] is responsible for initiating, completing, and documenting the incident investigation.
  • The ISO is responsible for coordinating communications with outside organizations and law enforcement.
  • In the case where law enforcement is not involved, the [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] will recommend disciplinary actions.
  • In the case where law enforcement is involved, the [SharePoint Portal Owning Organization / Incident Handling Unit labeled above] will act as the liaison between law enforcement and [Organization].
SharePoint Incident Management Policy Supporting Information
  • All [Organization] SharePoint users are responsible for managing their use of SharePoint and are accountable for their actions relating to SharePoint security. Users are also equally responsible for reporting any suspected or confirmed violations of this policy to the appropriate management responsible for SharePoint security incident handling.
  • The use of SharePoint must be for officially authorized business purposes only. There is no guarantee of personal privacy or access to tools such as, but not limited to; SharePoint areas, WSS team sites, any and all collaboration and communication functionality, and any sister sever integrations (i.e. integrated Microsoft Exchange environments). The use of Sharepoint and SharePoint related tools may be monitored to fulfill complaint or investigation requirements, including forensic an analysis into IDS or other security systems. Departments responsible for custody and operations of the SharePoint servers (custodian departments) shall be responsible for proper authorization of SharePoint server utilization, the establishment of effective use, and reporting of performance to management.
  • Any data housed within SharePoint must be kept confidential and secure by the respectful [Organization] SharePoint user. The fact that the business data may be stored electronically (i.e. document library or SharePoint list) does not change the requirement to keep the information confidential and secure. The type of information or the information itself is the basis for determining whether the data must be kept confidential and secure. Furthermore if this data is stored in a paper or electronic format, or if the data is copied, printed, or electronically transmitted the data must still be protected as confidential and secured.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All commercial SharePoint software used in [Organization]’s SharePoint environment (i.e. Web Parts) must be supported by a software license agreement that specifically describes the usage rights and restrictions of the product. SharePoint users must abide by all license agreements and must not illegally copy licensed software. [Organization] reserves the right to remove any unlicensed software from the SharePoint environment.
  • [Organization] reserves the right to remove any non-business related SharePoint software or files from the SharePoint environment.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share