Security is an important element of any system, and K2 blackpearl has a good offering of security features; however, software security features do equate to a secure system. Like all software, the security of K2 blackpearl goes well beyond the administration and management of authentication (who can login) and authorization (what they can access) or the APIs that provide the use and extensibility of security features, which are all certainly important critical core security features. Instead, the security of any individual system requires a holistic, enterprise-wide approach starting with buy-in from the highest levels of management, mandated to all employees through the policies, including the ability to execute and enforce these policies in an effective manner, while balancing the business needs with the security controls so that information security doesn't present unnecessary barriers to actually getting the work done. What a daunting task! This is because information security is not simply an IT function; it is also a business function.
With that said, there are many facets of information security to cover. When you survey K2 blackpearl, including all the interdependent systems, a picture emerges of an overwhelming task of securing it all — a task that's often ignored due to a lack of knowledge or put off due to time constraints. Since this book is not strictly for developers, this chapter will provide security administration from a business perspective as well as the technical aspects of K2 blackpearl's security administration for K2 administrators and programmers. The first half of this chapter briefly covers a broad spectrum of security principals by providing security awareness. The second half of this chapter delves into the specifics of K2 blackpearl's security offerings and how to best apply those security principals.
This chapter covers the following topics:
According to Breach Security's "Web Hacking Incident Database 2007 Annual Report,"[14] 67% of the incidents in 2007 were for-profit motivated, and in 44% of the incidents, sensitive information was stolen. The trend of security incidents and issues year after year is on a consistent upward trajectory and the increasingly common goal of computer hackers is profit, meaning that the systems and information compromised are likely to be used to cause harm to customers, shareholders, employees, and so on. The report also makes clear that the numbers are only the tip of the iceberg because many incidents aren't publically reported or the organizations are not aware that any security breach or security incident has even taken place. As network and operating systems' overall security improves, attackers are targeting Web applications more and more. Information Security must be taken seriously by all organizations. Organizations must be vigilant to protect employee information, customer information, and internal private or proprietary information.
According to FISMA (Federal Information Security Management Act of 2002, U.S. Code, Title 44, Chapter 35, Subchapter III, § 3542) "information security" is defined as:
. . .protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide —
integrity, which means guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity;
confidentiality, which means preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information; and
availability, which means ensuring timely and reliable access to and use of information.
These concepts, integrity, confidentiality, and availability, are commonly referred to as the CIA Triad. When thinking and planning the overall security of any computer system or systems, it helps to view securing them in this light.
There are two types of integrity to consider:
Data integrity : Which is concerned with data modifications being accomplished properly.
Source integrity : Which is concerned with confirming information actually originated from the source that it claims to come from. This also provides nonrepudiation (for example, the sender can't deny that they actually sent a message or performed an action).
An example of data integrity would be if a user or system is able to make an unauthorized modification to data as it moves from System A to System B; this would violate integrity; banks, as well as their customers, are especially concerned with data integrity when it comes to fund transfers.
With source integrity, in certain situations being able to verify that a piece of information originated from a particular person or system can prevent types of fraud. If messages are forged, much like the problems that plague the Internet e-mail system today, users can easily be tricked into giving up sensitive information (known as phishing). Some ways to help protect against data integrity violations are good data design, the the use of transactional operations, input validation, RAID parity, and mirroring technology, and encryption hash algorithms that can detect the modification of data while in transit or at rest. To provide source security, digital signatures can be used to validate the sender and additionally verify that the message was received unmodified.
Confidentiality is all about keeping secrets. Some common methods to help ensure confidentiality are:
Authentication
Authorization
Encryption
For example, if a Human Resources system requires storing Social Security numbers in a database, the application accessing the database and database itself must enforce authentication (users) and authorization (roles) to prevent unauthorized users from accessing that data. However, where most organizations get into trouble is by shrugging off the fact that the database administrator (DBA) as well as the local Administrators group have access (by default the Local Administrators group is added to the sysadmin role in SQL Server). This means that not only can the DBA access the Social Security numbers, but additionally every domain administrator can as well (if the local Administrators' group hasn't been removed from the dbo role in SQL Server and the SQL Server is a domain member). This is when encryption at the data column level must be deployed to prevent those who have access but are not authorized to see the information from doing so. Additionally the Local Administrators' group should be removed from the sysadmin role within SQL Server and replaced with a domain group that represents the SQL DBAs.
In order for an organization to know what data is confidential, it's important to go through a data classification process where all the information within a company is given a classification label (for example, Business Sensitive, Business Confidential, and so on.). Government agencies often already have these classifications defined. Once the information is classified, appropriate controls can be applied to protect data based on policy.
This concept is straightforward: If the data is not available for some reason, this tenant has been violated. Some examples of availability problems:
The database server is down.
A network switch/router/firewall/cable is malfunctioning or incorrectly configured.
Newly deployed code has bugs and is causing the system or parts of the system to fail or perform poorly or hang.
The server and network are unavailable because a hacker has performed a denial of service (DoS) attack.
Initially, it may not be obvious what availability has to do with information security but when you consider different scenarios, it becomes apparent why availability is in the definition of information security. Consider a business that strictly relies on the Internet, such as an e-commerce company. Every minute the Web site is down, that company is losing potential customers, sometimes permanently as consumers may switch to another, more reliable e-commerce Web site, causing major financial losses. Also consider the military — if a network or system that directly supports soldiers in the field goes down, it could limit their effectiveness or even cost lives. Some ways to protect systems against availability issues:
Making sure to plan for the proper load when building the systems and network
Using network and system redundancy with a backup UPS or power generator
Preventing unauthorized users from accessing critical systems
Preventing developers from deploying code to production systems before software has been adequately tested
Having solid testing processes and procedures before deploying new code
Having a back-out plan if deployed code happens to fail even after testing
Having data stored redundantly (RAID)
Having replacement hardware on hand in the case of a hardware failure
Designing an IT infrastructure that helps mitigate DoS attacks
Also, more extreme scenarios need to be considered. Does the organization have a Business Continuity Plan/disaster recovery plan? How long would an organization survive if the primary networking facility became unavailable for an extended period of time or permanently (for example, fire, hurricane, and so on)? Would the business recover? Chapter 18 will delve more into disaster recovery with K2 blackpearl.
One potential way of mitigating a long term availability failure with K2 blackpearl is by having a backup manual process that doesn't rely on any IT systems. This, of course, would require up-to-date available physical paper copies of any forms needed for a given process. This could allow an organization to function, at least partially, without the system or network for perhaps a few days if needed. It's also critical that employees are familiar with the alternate manual process as well as the automated one. Finally, a method for importing the outcomes of the manual process into the system after it's been restored would be necessary. Certain core features may be missing while it's offline, such as calculations or inventory lookups, so it might not be possible to have a full manual functioning process. This requires careful thought and planning.
It's worth noting that certain types of organizations may focus on one tenant more than the others. For example, the military would be most concerned with confidentiality of information and a financial institution may be more interested in protecting data integrity. This isn't to say that the other tenants of security aren't important or are ignored, it's just that one may stand out as clearly more critical to protect to the organization.
There is also another common security triad used in information security that doesn't completely fall under the CIA Triad that is important for organizations to understand as well. These are authentication, authorization, and accounting (auditing), often called AAA or Triple A.
Authentication: is responsible with identifying the user or system as they access a system. Actual identity can be a challenge to validate; just because a username and password have been presented doesn't necessarily prove the identity of that human or system. It just proves whoever is gaining access to the system knows the credentials needed to log in. To help resolve this difficult issue, multi-factor authentication methods will increase the ability of a system to validate the identity of the user logging in. In certain cases a username and password will suffice; in other cases, multi-factor authentication using Smart Cards can be employed to further assist in protecting assets. Additionally, an account shared between multiple people would violate this principal, since there would be no way to identify the actual person logging in (and no way to provide accounting as defined below).
Authorization : Speaks to what a user has access to do. These are the roles and privileges assigned to users to allow them to do what they can within a system. It's important to note that it is not the responsibility of a system administrator or database administrator to decide who is authorized to access a given system, data store, Web site, and so on. While it is the administrator's responsibility to grant access, it falls on the Data Owner to permit it. The Data Owner would be a top-level business manager that is responsible for that line of business. The Data Custodian would be the database and/or system administrators who manage the resource on behalf of the Data Owner.
Accounting : Tracks users, as authentication tracks what they do, and records successful and unsuccessful attempts to log in or gain access to specific data. This is critical for auditing systems and accountability. It's what gives administrators and auditors visibility into system abuse, attempted abuse, or problems with a system.
Applying AAA throughout the organization helps protect information assets and additionally provides a way to validate (audit) that assets are protected, or if a breach has occurred or has been attempted.
K2 blackpearl has many features to help facilitate AAA and CIA. Additionally, good software development practices and proper architecture planning and configuration can improve the implementations of CIA and AAA.
There's no such thing as 100% security.[15] Or to phrase it another way, there's no such thing as zero risk, so this should not be the goal of information security. Every organization has a threshold of what is an acceptable loss if any of the tenants of the CIA Triad described earlier are violated. A better, more realistic goal is to calculate, estimate, or "ballpark" the level of risk to an enterprise's assets and attempt to lower the risk to these to an acceptable level. Before going any further it's important to mention that there are entire books written on the topic of risk analysis and by no means will the couple of paragraphs here attempt to be exhaustive, but instead hope to convey a framework for thinking about the information security of these systems and how much effort should be applied to a system's security.
Risk analysis helps an organization prioritize where to direct their information security programs based on the goals and priorities of the business itself. Without risk analysis, the security functions within an organization will choose priorities and goals whether they align with the priorities of the business or not; this disconnect can often cause conflict and even confusion within the organization as the functional business units clash with the security controls forced onto the organization. This often results in asymmetric and sometimes odd security policies and controls, and the inconsistent enforcement of security rules imposed on an organization. This isn't to say that when the business priorities align with the security functions of an organization that the security policy and controls won't cause friction within the organization. However, a strong case can be made for such policies and security controls, and thus it will be easier to get buy-in from management as well as support from the employees within the organization. It's important to have a basic, employee-targeted security training program because without it users may be lax or resistant to security controls if they don't understand why they have been put in place.
There are two common approaches to risk analysis — quantitative risk analysis and qualitative risk analysis:
Quantitative risk analysis: Focuses on assigning objective numeric values to assets, enumerating the vulnerabilities and threats to these assets and the probability of these threats occurring. Once these risks are assessed, the cost of each countermeasure is weighed against the value of the assets they protect and economically reasonable safeguards are chosen — all based on the numbers. This can be a difficult and time-consuming approach, since it requires intimate knowledge of assets' worth, as well as intimate knowledge of all the risks, including the probability such risks can occur and the visible and hidden costs it would take to mitigate any given vulnerability. For the inexperienced, such a detailed analysis is time-consuming and has the potential to paralyze the risk assessment process. This process can take so long that by the time the organization is ready to roll out the countermeasures, the environment has changed significantly affecting the outcome of the risk analysis since all the information gathered is now out-of-date. Quantitative risk analysis is often done by a third-party consulting firm that specializes in risk analysis, and/or specialized software packages are used so that the analysis can be completed in a timely fashion.
The more common approach, qualitative risk analysis: Focuses not on hard concrete numbers but instead on estimations and even informed opinions. The assets and risks to asset values are ranked categorically or numerically and then dealt with in order of highest risk to lowest risk. This can be done fairly quickly; however, since there aren't hard numbers, it may difficult to tell if a chosen countermeasure is cost-effective.[16]
This brief introduction on risk assessment aside, the important thing to understand about risk analysis is this: One of the main goals is to help direct the focus to the items requiring the most attention — those items that are most valuable and have the highest risk. Understanding which assets have higher values/higher risks prevents the wasting of time and money on systems with either little value or on items with low risk. Then time and effort can be put towards administrative controls — that is, the policies, procedures, standards, guidelines, logical or technical controls that are software based, and finally physical controls that protect the IT infrastructure from physical threats in the real world.
This brings us back to K2 blackpearl. Depending on the particulars of a K2 blackpearl implementation in a given environment, it stands to reason that the K2 blackpearl system can have data from just about any system in an enterprise pass through it and/or be stored within it. It also could potentially contain the credentials to pull data from back-end systems as well. Since data from many different systems can be accessible to or stored within K2 blackpearl and a large part of the enterprise may rely on it to function, it has the potential to be a highly valued asset with many potential risks.
All this to say: Because of the type of data potentially moving through K2 blackpearl and the heavy reliance on K2 as a core system within an enterprise, an organization cannot afford to gloss over the security of such an important core piece of technology, K2 blackpearl, including the systems that K2 blackpearl interacts with and are dependent on.
While risk assessments can help guide the security posture and the safeguards placed on particular IT systems, there are other factors that will require additional due care to be taken with IT systems — namely the Security Policy as well as laws and/or regulations that apply to a particular industry, public corporation, or government organization.
The Security Policy is an organic document that "states in writing how a company plans to protect the company's physical and information technology assets."[17]
Familiarity with the Security Policy is important because it defines at a high level the expectations placed on employees in the organization to maintain the information security for the organization. Whether they are employees, contractors, or consultants, everyone should be aware of the security posture and policies of the organization. The security policy must be mandatory for ALL employees, no exceptions. If an organization does not have a Security Policy, that also may reveal a bit about its security posture. The responsibility lies with the decision makers at the highest level of an organization to set the security expectations through the Security Policy. Even if one does not exist, it is still important that each individual involved practice due diligence in security, looking to industry standards and best practices. Another important feature of the security policy is that it provides a foundation for enforcement. If an organization has a security policy in place without enforcement, then the policy will not work, and the information security of the organization suffers.[18],[19]
There may also be other documents to be aware of when deploying a new K2 blackpearl installation or designing a workflow for an existing K2 installation. The primary stakeholders must be aware of and current on industry and organizational policies, standards, guidelines, and procedures so care is taken to make sure a deployment can have the authority to operate within an organization. It's not unheard of for a system that meets a functional business need to be built, paid for, and deployed and then have its "authority to operate" pulled and be taken off the network because the system contains unprotected sensitive data or suffers from serious security flaws.
For example, the Defense Information System Agency (DISA) of the U.S. Department of Defense (DoD) has Security Technical Implementation Guides (STIGs) — these in combination with the NSA Guides act as the standard for how to configure computer systems that operate on any DoD network. When a new system is added to the network, it is required to be configured in accordance with these standards. Another example is PCI DSS, the Payment Card Industry (PCI), which is made up of the major credit card companies. It released the Data Security Standards (DSS) as a baseline for securing systems and networks that handle payment-processing information.
Aside from the internal documentation created by an organization (the policies, procedures, policies, guidelines, and standards), there may also be regulations and laws placed on organizations that mandate certain expectations and consequences for failing to protect information within an organization.
Legal and regulatory compliance may dictate how an organization can store, protect, and share data, or perhaps how long it should be stored, what should be logged and audited, and so on. It's critical to talk with the Legal department about the implications of laws on a K2 blackpearl process, especially if it contains sensitive or classified data, personally identifiable information (PII), financials, and so on. Some laws will require auditability, others may require the proper handling of sensitive data, and others yet may require public disclosure of any security incident that happens within an organization.
The following table provides some examples of U.S laws, the industry/organizations they affect, and a brief description of what protection they attempt to provide. Make sure to check not only the laws in the country the organization is headquartered in but also the laws of other countries the organization does business in or has a business presence in, as these laws may also apply to the organization.
Industry/Organization Affected | Brief Description | |
|---|---|---|
U.S. federal/state/local government | Helps prevent the abuse of privacy information. | |
FISMA — Federal Information Security Act of 2002 | U.S. federal government and affiliated parties (for example, contractors) | Increases IT Security by mandating a common set of processes for managing and configuring IT systems. |
U.S. federal government | Helps protect personal privacy and national security information. | |
HIPPA — Health Insurance Portability and Accountability Act | Healthcare/ health insurance industry | Helps prevent fraud and abuse. |
Financial firms | Requires a formal security plan as well as protections for customers to help prevent the exposure of sensitive information. | |
Sarbanes-Oxley Act of 2002 (SOX) | U.S. public company boards; accounting firms | Mandates requirements for financial reporting. |
The bottom line is this: Talk with each stakeholder whose data will be accessed via K2 blackpearl or the business owner of the system being developed. They should be aware of laws and regulations that apply to the organization's industry or organization. Also check with the legal department for laws and regulations that must be followed, and finally make sure to follow industry security best practices when setting up each system that will interface with K2 blackpearl. Practicing due care and due diligence by following industry security standards and best practices can provide protection from negligence. Remember, ignorance will not protect an organization from liability. The final ultimate responsibility for information security falls on the highest-level managers, not the technicians.
Deploying K2 blackpearl can be quite the undertaking, since it has the capability to integrate and interoperate with just about any other system in the enterprise. Before delving into the aspects of security that K2 blackpearl provides within the product, it's important to start with securing the environment K2 will run in. This includes the network infrastructure, server operating systems, and perimeter security such as firewalls.
Get organized! Take the time to plan, document, and map out the K2 blackpearl deployment taking care to include all the software that will integrate with K2 blackpearl, be it Windows SharePoint Server 3.0 (WSS/MOSS), SQL Reporting Services 2005, IIS, and so on . Your organization may already have guidelines for systems documentation requirements. If so, start with those. However, they may not be exhaustive, so it will be helpful to add additional information.
The documentation will start with the deployment plan and architectural template discussed in Chapter 5. Additionally, it will be helpful to document all the additional pieces of information needed to set up and configure the entire infrastructure from scratch. This will also be critical for Business Continuity/disaster recovery (see Chapter 18 for more information on disaster recovery). The K2 blackpearl Installation Guide in the K2 blackpearl documentation also contains an Excel Workbook to document the installation process.
The following list contains information that will be helpful to document. This list is not exhaustive, but will provide a good starting point:
The DNS names and corresponding IP addresses for each Web site, database server, and also server names (as there may be multiple names and or IPs per system).
Internet Information Services sites and applications that will access K2 blackpearl and the corresponding IIS configuration settings.
SSL certificates required, including the fully qualified domain name (FQDN).
The software and subcomponents and the corresponding systems, based on the architectural template used from Chapter 5.
Installation folders where the applications will be installed (security best practices recommend software be installed on a separate drive then the OS partition to protect against canonicalization attacks).
Planned application log folders for each server. Also document how verbose each log will be set on which servers for each corresponding service.
Service accounts that will run the services of the software being installed.
A logical network diagram, including firewall locations and the corresponding network ports that must be opened for the systems to function.
If unfamiliar with the K2 blackpearl installation process and configuration, invest in the time to become familiar with it by installing it on a virtual PC first, taking care to test the installation process, permissions required to install, how the product handles security internally, and operating system privileges required for the proper functioning of the system. Virtualization provides rollback abilities so mistakes can be undone, which can save time if problems are encountered while getting familiar with the software. This virtual image will serve as the proof of concept for an actual deployment and a playground for trying new things, patches, configuration settings, and so on. It's critical to have a level of competence and comfort with software before deploying it on any system for consumption, be it a development, staging, or production system. Once the system has been deployed and adopted, it is often difficult or impossible to make major changes to the installation since it may affect the availability of the system, meaning your organization may have to live with any mistakes you make during deployment.
Familiarity with the software, good documentation, and planning reduces the possibility of making mistakes during the final production installations (including test and/or staging environments) and assists with avoiding skipping important steps in the installation and securing process. This process will also serve to create an architecture diagram of the entire installation, which is often required as part of a project anyway but is often missing. Not only will this documentation assist in troubleshooting, but it will also help other administrators to understand what's been installed, how it's configured, what accounts are used, and what other dependent systems are involved. This will facilitate understanding of the K2 system and all its interdependencies, improving the organization's ability to troubleshoot issues, especially in the situation where the individual who integrated the servers into the environment is unavailable for some reason. Additionally, take extensive notes during the installation, documenting every step. Complete documentation on how to install and configure each software component as well as each server as it has been configured in the environment will aid in disaster recovery/Business Continuity plans.
If the availability of the K2 workflow engine affects an organization's ability to complete one of its core business functions and ends up creating a work stoppage, financial losses may result. Good up-to-date documentation and training at least one other administrator on the K2 blackpearl deployments is critical. For example, assume that the K2 server goes down and there are 75 users sitting with nothing to do, that is, orders aren't getting processed or customers aren't receiving the support or attention they need. If administrators are unable to bring the system back online because the one who did the installation and configuration is on vacation or was a consultant, that can potentially lead to real problems. Since availability is one of the core tenants of security, an unavailable system is classified as a security threat and should be taken into account during the risk assessment, and work should be done to mitigate it to reduce downtime. To help mitigate such risks, it's critical that multiple administrators understand how the K2 system has been integrated into their environment, what servers are involved, and what accounts are used to run the services, and how everything is configured. Also, a solid regularly updated and validated disaster recovery plan should be in place that includes all of the documentation created as part of the installation and system hardening process.
Finally, this documentation will serve as a checklist for all the items that need to be configured and the areas to focus on when securing.
After having planned and mapped out the K2 blackpearl installation and installation completes successfully, the final step is to harden, or increase the security, of all the servers and services that have been installed. Depending on the architectural template chosen, there may be only one server to harden or several.
There are industry and government standards for hardening operating systems, with varying levels of protections to implement depending on what the system is used for and the types of information available to the system. Initially, this process can be time-consuming and somewhat overwhelming. The goal is to automate this process as much as possible so it's repeatable and can be done quickly. Once the task is completed, schedule to resecure it on an ongoing basis because over time security settings often are removed or changed by administrators or application patches. If a security configuration change should be made permanent, don't forget to go back and update the documentation and automation files.
There are sources available on the Internet that have security checklists based on industry standards for configuring operating systems, networking equipment, application servers, and so on. By building up a library of Active Directory Group Policies, Security Templates, Registry files (.reg) and scripts, a system (for example, Web server, database server, K2 blackpearl server) can be realistically hardened in a reasonably short period of time. There is a learning curve to server hardening, so it's a skill that needs to be developed, but once an administrator has familiarity with the process, it doesn't take as much time.
There are security benchmarks and scoring tools available as well to help automate the scanning, detection, and configuring of systems. One place to download tools and checklists is The Center for Internet Security (www.cisecurity.org). The NSA and Department of Defense also have guides and checklists available online for the Gold and Platinum security standards for operating systems as well as Security Implementation Guides for server products. The Defense Information Systems Agency's guides are located at http://iase.disa.mil/stigs/index.html and the NSA guides are located at www.nsa.gov/snac.
Note
There is a level of risk involved with securing any system without understanding the relationship between security settings on the system and the affect it has on the software installed on that system, including the system's ability to communicate with another system on the network. Some recommend security settings can and will completely break either the applications or the servers themselves. Some of the Local Security Policy settings may need to be set domain-or forest-wide to maintain system communication. While automating system security is critical, make sure to test settings or groups of related settings incrementally. That way, if a particular setting breaks something on a server, it's easy to roll back the change and document the incompatibility so that it won't be accidently applied later.
The principal of least privilege is a simple but important concept. The principal is this: Grant only the minimum amount of access required for an account to accomplish the tasks required and no more.
This applies to both users and services. If a user needs visibility to a K2 blackpearl process, it would be inappropriate to grant the user the "process admin" permission, although that would certainly work. The problem is that it would give the user the ability to go beyond what's required of them, and they could potentially cause problems. Instead make sure to grant them the View Participate permission (more on K2 blackpearl permissions later in this chapter).
This principal not only applies to users, but it also applies to service accounts. K2 blackpearl's Host Server runs as a Windows Service; during installation, it is configured with an Identity (typically called a service account). In order for K2 blackpearl to function properly, it needs to be granted certain permissions and privileges within the operating system. What's tempting for most administrators is to just add a service account to the Administrators' group on the local machine to try to solve a problem the service may be having. While this may solve the problem, it also may create a more serious problem. If, by chance, the service has a vulnerability and it gets exploited, then because the service is running with administrative rights, it may not only have administrative access to the computer with the vulnerable service but potentially to the entire domain.
A common argument against applying least privilege is that a user wouldn't do the wrong thing, for example, "Bob would never delete those files with critical corporate data," or "Bob wouldn't steal that sensitive data because we trust him, so we don't mind making him an administrator on that server or granting him rights to those files." There are a couple of problems with this argument. Bob may accidently do something he didn't mean to or if Bob's account is compromised, someone will do something with Bob's account that he shouldn't have been able to. Either way, Bob may be held responsible for the actions on that computer when in actuality, the fault is not necessarily Bob's but with the lax security policy or the implementation of the policy.
The principal of Least Privilege can protect employees, systems, and the organization.
This step provides several security benefits. If you reduce the software installed, fewer software patches will be required and therefore administrative overhead will be reduced. This also reduces the potential attack vectors available for hackers to exploit by eliminating potential vulnerabilities and therefore decreasing risk. Last, it will free up system resources (memory, disk, CPU), which will also have a positive effect on the availability of a system.
The principal goes something like this:
Install only software that is required for the server to function.
Disable/uninstall everything else.
The more software installed on the system and the more OS features enabled on a server, the greater the potential that the system will contain vulnerable components to exploit. A skilled hacker could use multiple vulnerabilities in multiple services on the same machine in concert to take a seemly limited exploit and escalate it to full—blown access. So not only should administrators not install unneeded software, they also should uninstall and disable operating system features that aren't required to support the application on the server and additionally disable any Windows Services that are not needed. Once the service is marked Disabled, the Discretionary Access Control List (DACL) for that service should then be modified to only allow two accounts have full control and the rest just have read permissions. This prevents a service from being started. The Windows Service security descriptor and startup modes (Automatic, Manual, and Disabled) can be set using the Security Configuration and Analysis Tool or using the sc.exe command-line tool. Using these tools, .inf files or batch files can be created to automate this process for many different servers, providing that the accounts being configured are the same across those different servers (for example, Administrators, SYSTEM). The following table shows the permissions that should be granted to a disabled service to prevent it from being started by anyone but an administrator. Save a copy of these files for automating system hardening, and documentation. It will come in handy if the server needs to be rebuilt from scratch.
Account | Discretionary Access Control List (DACL) Assignment |
|---|---|
Local Administrators | Full Control |
SYSTEM | Full Control |
Users | Read |
As mentioned previously, this also provides the benefit of freeing up additional memory and system resources for the server to use, so it's really a win-win.
Make sure to test all settings on a test system first before attempting this on a production system as some services are required for the K2 server to function properly. Some services may need to be reenabled during software installation or patching. For example, in some environments there are requirements to disabled the Scheduled Task Service. Normally this isn't a big deal, but if you are using Clustering Services and an attempt is made to install or patch the cluster aware software, the installation cluster node may require the Scheduled Task Service to automatically kick-off the installation on the other cluster node. In some cases it may be necessary to reenable a disabled service while patching.
Separation of duties provides checks and balances among individuals. It can limit the amount of damage any one person can inflict on an organization, either intentionally or unintentionally. This concept is not foreign to banks, retail stores, or military agencies. Areas where there is a conflict of interest often are good candidates to apply separation of duties.
The common cinematic scene in the war movie comes to mind when the military is ready to launch the nukes; the command comes down separate chains-of-command to two soldiers. They are each given codes to get the keys. Both must enter the keys to retrieve the code and insert their keys and turn them at the same time. This prevents one rogue individual from launching the bomb without a conspiracy.
In information security, IT staff may be separate from the IT security staff: one group would be responsible for the management and administration of IT servers, and the security group would be responsible for auditing and monitoring the security of the systems managed by the IT staff to make sure that the policy was followed.
The logging configuration is an important, but often overlooked step. Or if logging has been configured, it isn't monitored. Logs not only help you to troubleshoot issues, which is almost the only time they are reviewed, but they also can identify system attacks, potential availability issues, configuration problems, and other similar types of information. Log files should not be written to the application installation folders, as this often means the privileges within those folders need to be elevated. Instead, the log files should be configured to be on their own. Once the logging verbosity and file locations are configured appropriately, these folders also need to be secured. Only the service accounts for each corresponding service will need the ability to write to them. In order to prevent log tampering, no other accounts should be granted access to these folders except for administrators and the auditing group, if such a group exists within the organization. For the strictest environments, only the auditors should be configured to delete any logs. Administrators should only be granted Read permissions. The service account should be granted Modify or Full Control, depending on how the software manages its log files.
Also make sure the Audit Policy has been configured properly so important events are captured in the Application, Security, and System Event logs. Open the Local Security Settings (secpol.msc) MMC. Open Local Policies
The log files should be examined on a regular basis, including the Event logs. Anomalies and errors should be investigated and resolved.
For configuration details on K2 blackpearl logging, see Chapter 19.
To make sure that the principal of least privilege is followed, the goal is to configure the K2 Server Service account and the IIS Worker Group account with the minimum privileges needed on the operating system. Here are the areas to focus on:
Kerberos configuration (See Chapter 5 on planning an effective deployment.)
Windows operating system privileges
File and folder permissions
Registry permissions
SharePoint permissions
SQL Server permissions
SQL Reporting Services permissions
K2 Workspace permissions
K2 Performance Monitoring permissions
MSMQ permissions
The installation account is the account used to do the K2 blackpearl installation; it should always have administrative privileges on the server where the installation will take place, and with K2 blackpearl it's also helpful to have Domain Administrative permissions so the installer can set up the Service Principal Names in Active Directory to assist with automating the configuration of Kerberos. Additionally, make sure that the account also has sysadmin privileges on the SQL Server so that it can create, configure, and populate the databases. This will allow for a smooth installation. If there is no account that meets these requirements, create one for use during the installation of K2 blackpearl and also use this account for applying product patches and service packs. Leaving this account with such a broad range of permissions in the environment may be risky, so when it is not in use, disable this account or remove any elevated permissions and reapply them when the account is needed.
There are several service accounts that will need to be set up and configured for the complete K2 blackpearl installation. The following table lists the server component and the corresponding name that will be used to refer to the service account:
Component | Service Account Name |
|---|---|
K2 blackpearl Installer | Installation Account |
K2 blackpearl server | K2 Service Account |
K2 blackpearl Workspace | K2 Workspace Service Account |
Microsoft Office SharePoint Server (MOSS) 2007 | SharePoint Service Account |
SQL 2005 Reporting Services | Reporting Service Accounts (App Pool Identity and Windows Service Identity) |
For maximum security, each service should be configured to run under a different account. Additionally Authenticated Users or a more limited group will need permissions on different servers as noted in the next section.
The System Account Requirements topic in the K2 blackpearl Getting Started Guide recommends that the K2 Service account be granted local administrator rights on the server. From a configuration and management perspective, this makes K2 blackpearl easier to install, configure, and maintain, as just about any request the K2 server makes of the operating system will be granted on the local system because it has a high level of rights and privileges on that system.
From an information security perspective, this may create unnecessary risk and may also be restricted by your organization's security policy. If the K2 Service Account is granted local administrative permissions, any vulnerability in IIS, ASP.NET, or K2 blackpearl could grant a user full administrative access to the system, allowing them to do anything they wished with the server. This does not conform to the principal of least privilege or defense in depth described previously. Instead, remove the K2 Service account from the local Administrators' group. However, understand that additional manual configuration will be required. This section will document the settings needed to grant the least amount of privileges needed to set up.
To make sure installation completes successfully, make sure that the K2 server has started at least once while the K2 Service account is in the Administrators' group. This will allow K2 to complete some additional setup and configuration tasks that happen the first time the server starts up. If not, you will have to perform these manually. For instance, K2 creates the MSMQ message queues for the Event Bus the first time it starts up.
Note
If for some reason you change the K2 Service account to a different Domain account, K2 blackpearl will no longer have the proper access to the cryptographic keys. It is possible to change the service account to a different user, but be warned that some additional steps will be needed to allow the new service account access to those cryptographic keys. See the section titled "File and Folder Permissions" later in this chapter for more information.
When ASP.NET Web sites are hosted in IIS 6.0 and above, they require an identity for the Web application code to execute. All Web applications assigned to that application pool will run as that identity.
The SharePoint Service account is the identity the SharePoint Web Site Application Pool runs under. If SharePoint already exists in the environment, this service account will already exist. For K2 blackpearl to integrate properly with SharePoint, additional permissions need to be configured.
There could be potentially two Reporting Service accounts. One is the identity that the Reporting Service Web Site Application Pool runs under. The other is the Account that the SQL Reporting Service runs under. For K2 blackpearl to interface with the Reporting Services, the K2 Service account will need to be granted an appropriate application role within reporting services. SQL Reporting Services accesses a K2 Data Store through a custom provider. By configuring Kerberos and delegation permissions for the Reporting Server, this will allow SQL Reporting Server to impersonate users when they connect to K2, and then K2 permissions will apply when running the reports.
The following table documents the minimum operating system privileges needed to function for K2 blackpearl Service and the IIS Worker Process:
Account | Privilege |
|---|---|
K2 Service Account | Requires the "Log on as a Service" privilege. |
Adding this account to the IIS_WPG group will automatically grant it the operating system privileges needed for the K2 Workspace ASP.NET Web site to function. |
To grant the "Log on as a Service" privilege:
Open the Local Security Settings (
secpol.msc) MMC.Open Local Policies
Add the K2 Service account to the list.
Figure 16-2 shows an example of the Local Security Policy settings.
The "Log on as a service" right should be granted automatically when setting the Credentials for K2 blackpearl server Service in the Services Console MMC.
The goal in securing the file system is to only allow the service accounts the minimum access to the folders and files required. Before installing any software, including the operating system, all drives should be formatted using the NTFS file systems.
If installing K2 blackpearl on another drive than
%systemroot%(which is typically the C drive), remember that any additional drives created and formatted NTFS are granted excessive permissions. For example, if you are creating a new E drive, make sure to remove all the permissions on the root of that drive except SYSTEM and the local built-in Administrators' group. They should both have Full Control. When installing the software, the installer should set up the proper ACL's for each folder using the accounts specified. Then you manually need to add each service account as well to those drives with Read/Execute permissions.
The following table documents the file and folder-level permissions required for the K2 Service account on the K2 server:
Account | Rights | Folder |
|---|---|---|
K2 Service Account | Full Control | %SYSTEMROOT% emp |
K2 Service Account | Full Control | %ALLUSERSPROFILE%Application DataMicrosoftCryptoRSA [14]This setting is NOT typically needed. See the security footnote for a better workaround. |
K2 Service Account | Read & Execute | %SYSTEMROOT%Microsoft.NETFrameworkv2.0.50727CONFIG |
K2 Service Account | Read & Execute | [K2 Install Path]K2 blackpearl All subfolders and files, all K2 Logging should be configured to write to a folder outside of this path. |
K2 Service Account | Modify | [K2 Install Path]K2 blackpearlHost ServerBinK2HostServer.config The service account needs write access to automatically encrypt connection strings in the K2HostServer.config file. |
K2 Service Account | Create Folders | [K2 Install Path]K2 blackpearlHost ServerBin Important: Set the Apply onto drop-down to This folder only (Figure 16-3 shows how to configure this setting). |
CREATOR OWNER | Full Control | [K2 Install Path]K2 blackpearlHost Serverin Important: Set the Apply Onto to Subfolders only When the K2 Service account creates the Work folder, it is the CREATOR OWNER. By granting this permission, it will have full control over the Work subfolder only. |
[a] WARNING! Granting Full Control to the RSA folder is not recommended, but it will work around a problem created when switching the K2 User Account to run under a different user since the cryptographic key was created while running under the previous account. Instead of changing the ACLs on the RSA folder as the table suggests, fix the problem by reconfiguring the encrypted database connection string section in the | ||
The following table documents the permissions needed on the K2 Workspace Web server:
Account | Rights | Folder |
|---|---|---|
Authenticated Users[15] | Read and Execute | [K2 Install Path]K2 blackpearlWorkspace |
Authenticated Users[15] | Read and Execute | [K2 Install Path]K2 blackpearlWebServices |
Authenticated Users[15] | Read and Execute | %SYSTEMROOT% emp |
[a] If a subset of Domain Users will be using K2 blackpearl, create a group in Active Directory and assign that instead of Authenticated users. This is especially useful for the development and review environments as only a limited number of users should have access to them. | ||
The following table documents the permissions needed on the SharePoint Web server:
Account | Rights | Folder |
|---|---|---|
K2 Service Account | Full Control | %SYSTEMROOT% emp |
K2 Service Account | Full Control | %ALLUSERSPROFILE%Application DataMicrosoftCryptoRSA |
K2 Service Account | Full Control | %SYSTEMROOT%Microsoft.NETFrameworkv2.0.50727CONFIG |
K2 Service Account | Write Access | %COMMONPROGRAMFILES%Microsoft Sharedweb server extensions12 Note: If installing SharePoint in a non-standard location, make sure to include that additional path. |
Authenticated Users[16] | Modify | %COMMONPROGRAMFILES%Microsoft Sharedweb server extensions12 Note: If installing SharePoint in a non-standard location, make sure to include that additional path. |
[a] If only a subset of Domain Users will be using K2 blackpearl and the corresponding SQL Reporting Services, create a group in Active Directory and assign that instead of Authenticated users. This is especially useful for the development and review environments as only a limited number of users should have access to them. | ||
The following table documents the permissions needed on the SharePoint Web server:
Account | Rights | Folder |
|---|---|---|
SharePoint Service Account | Modify | %SYSTEMROOT% emp |
SharePoint Service Account | Write | %COMMONPROGRAMFILES%Microsoft Sharedweb server extensions12LayoutsFeatures |
SharePoint Service Account | Write | %COMMONPROGRAMFILES%Microsoft Sharedweb server extensions12ISAPI |
The following table documents the permissions needed on the SQL Reporting Services Web server:
Account | Rights | Folder |
|---|---|---|
Authenticated Users[17] | Read and Execute | %SYSTEMROOT% emp |
[a] If only a subset of Domain Users will be using K2 blackpearl and the corresponding SQL Reporting Services, create a group in Active Directory and assign that instead of Authenticated users. This is especially useful for development and review environments since only a limited number of users should have access. | ||
Grant the listed accounts permissions on the following Registry keys.
For K2 blackpearl server:
Account | Rights | Registry Key |
|---|---|---|
K2 Service Account | Full Control | HKEY_LOCAL_MACHINESOFTWARESourceCodeLogging |
For Microsoft Office SharePoint Server:
Account | Rights | Registry Key |
|---|---|---|
K2 Service Account | Full Control | HKLMSOFTWARESourceCodeLogging |
In order for the K2 Designer to function within SharePoint, the K2 Service account will need to be granted the Site Collector Administrator role.
Account | SharePoint Role |
|---|---|
K2 Service Account | Site Collector Administrator |
Additionally for K2 blackpearl reporting to function, the K2 Workspace Service account will need to be configured as a Content Manager within Reporting Services.
Account | Role |
|---|---|
K2 Workspace Service Account | Content Manager |
The K2 Web Designer for SharePoint requires specific Database permissions to function. The following table documents the required permissions:
Account | Target Object | |
|---|---|---|
db_DataReader | SharePoint Service account | WebWorkflow database |
db_DataWriter | SharePoint Service account | WebWorkflow database |
Execute | SharePoint Service account | All Stored Procedures in the WebWorkflow database[18] |
[a] Best practice is to create a database role and grant the execute permission for each stored procedure to this role, and add the SharePoint Service account to that role. | ||
In order for some of the K2 integration with SharePoint to function properly, the SharePoint Service account needs the ability to export Workflows to facilitate the K2 Web Designer for SharePoint. Additionally the SharePoint Service account needs to impersonate users on the K2 blackpearl server so SharePoint can do tasks on behalf of users. The following table lists the Server Rights required for the SharePoint Service account when integrating K2 blackpearl with MOSS or WSS:
Account | K2 Server Rights |
|---|---|
SharePoint Service account | Export |
SharePoint Service account | Impersonate |
If K2 Performance Monitoring has been installed, the K2 Service account must be added to the local Administrators' group. Instead, to apply least privilege, there are a group of specific permissions required for the K2 Service account to use the Performance Monitoring and not require being added to the local Administrators' group.
The following table documents the File permissions required to allow the performance monitors to work with K2 blackpearl:
Account | Rights | Folder |
|---|---|---|
K2 Service Account | Write Attribute | %systemroot%system32lodctr.exe |
K2 Service Account | Write Attribute | %systemroot%system32unlodctr.exe |
K2 Service Account | Modify | %systemroot%system32perfc009.dat |
K2 Service Account | Modify | %systemroot%system32perfh009.dat |
The following table documents the Registry permissions required to allow the performance monitors to work with K2 blackpearl:
Rights | Registry Key | |
|---|---|---|
K2 Service Account | Read Control Query Value Set Value Create Subkey Enumerate Subkeys Notify | HKLMSOFTWAREMicrosoftWindows NTCurrentVersionPerflib |
K2 Service Account | Read Control Query Value Set Value Create Subkey Enumerate Subkeys Notify | HKLMSYSTEMControlSet001Services |
K2 Service Account | Full Control | HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTracing |
K2 blackpearl utilizes Microsoft Message Queuing (MSMQ) to support the K2 logging infrastructure as well as the Event Bus. After installation, on the initial run of K2 blackpearl, it creates two message queues for Event Bus called eventbus and eventbus error. So for the Event Bus to function properly, the K2 Service account requires Create permissions on the MSMQ server (by default the K2 Service account is granted the permissions to create the queues because it's put in the Administrators' group during installation). Once these queues are created, permissions can be relaxed. The following table shows the permissions needed:
Account | Rights | Queue Name |
|---|---|---|
K2 Service Account | Receive Message Peek Message Receive Journal Message Get Properties Get Permissions Send Message |
|
K2 Service Account | Receive Message Peek Message Receive Journal Message Get Properties Get Permissions Send Message |
|
Additionally, if you are using MSMQ Logging, the HostServerLogging.config file references a private queue called private$SCQueue. If this queue doesn't exist, the Host Server will attempt to create it, which will require Create permissions to be granted at that time, or an administrator can create the queue manually and then grant the permissions to the K2 Service account directly.
K2 blackpearl comes with a service called the Discovery Service that allows the K2 Workspace or any component that makes an API call to discover the K2 blackpearl servers on the network. The Discovery Service listens on UDP Port 49599 (see DiscoveryService.config in the [K2 Install Path]k2 blackpearlHost Serverin folder to view or change the default port). When a component wants to discover the K2 servers in the environment, a call to the Discovery API will send out a broadcast datagram to the network. If the broadcast datagram is seen by the Discovery Service running on the K2 blackpearl Service, it will respond back directly to the system that initiated the broadcast and transmit the K2 blackpearl server's hostname, and Host Server port.
In environments with more stringent security requirements, it may be requested that this service be disabled so that it can't be discovered on the network. To disable the Discovery Service, simply remove the SourceCode.DiscoveryService.dll from the HostedServices in the [K2 Install Path]Host Serverin folder.
Security requirements for your specific environment may mandate the confidentiality of data that moves through a K2 blackpearl workflow. If personally identifiable information (PII) — for example, Social Security numbers, birth dates, personal names, and addresses — are fields within the processes or are used by SmartObjects, then communications should be encrypted over-the-wire. Additionally, corporate data or government data that has been assigned a security label — for example, Confidential, For Official Use Only (FOUO), and Sensitive — should also be taken into consideration when making the determination that data should be encrypted over-the-wire.
The architectural template chosen for the K2 blackpearl system architecture will affect the scope of what communication channels need to be encrypted. For example, if you are deploying a single server deployment where everything is installed on one server — K2 blackpearl, SQL Server, SQL Reporting Services, IIS, and WSS or MOSS — the only data that is transmitted over-the-wire will be the Web traffic from Web clients. In this scenario, only the Web traffic will need to be encrypted. However, if you are deploying the medium-scale architecture, there are more points of encryption that will be required.
There are a couple of different approaches that can be used to encrypt data communications for a given K2 topology — TLS/SSL and IPSec. All Web connectivity, including the Web services should use TLS/SSL Certificates, including K2 Workspace, Microsoft Office SharePoint, and SQL 2005 Reporting Services. Additionally all SQL Server connections can also be encrypted using SSL certificates. K2 blackpearl doesn't natively support encrypting its communication channels over-the-wire, so an add-on network encryption technology like IPSec can be used. IPSec is network encryption protocol that is available in Windows Server productions as well as Windows Desktop operating systems and can be used to encrypt data on specific ports and protocols. Additionally, third-party software and hardware can also be used to deploy IPSec communication between servers. Take care to not leave any significant gaps of unencrypted traffic when deploying IPSec with a hardware solution.
An additional layer of protection can be added by requiring Client Certificates on the Web Interfaces for SharePoint, SQL Reporting Services, and the K2 Workspace.
Note
Enabling client certificates on the http://[k2webserver]/RuntimeServices folder in IIS may break certain features of K2 blackpearl or may require an additional level of configuration and/or programming for items that consume these Web services.
The specifics of how to configure SSL/TLS with IIS, and SQL Server and IPSec with K2 blackpearl are beyond the scope of this book.
See the following links for more information:
Certificates (IIS 6.0):
www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f8f81568-31f2-4210-9982-b9391afc30eb.mspx?mfr=trueHow to Enable SSL Encryption for an Instance of SQL Server by Using Microsoft Management Console:
support.microsoft.com/kb/316898Configuring a Report Server for Secure Sockets Layer (SSL) Connections:
technet.microsoft.com/en-us/library/ms345223.aspxIPSec on Microsoft Technet:
technet.microsoft.com/en-us/network/bb531150.aspx
Additionally, for WSS 3.0 SSL Configuration, see the WSS 3.0 installation documentation.
The second part of this chapter is dedicated to the security features provided with K2 blackpearl:
K2 blackpearl comes with two authentication providers:
Active Directory–based authentication: The Active Directory provider will work with the organization's current Active Directory infrastructure to authenticate users and to provide authorization within K2 using Groups.
A K2 SQL authentication provider that is in the works (targeted to be released with Service Pack 2): The K2 SQL provider allows an additional mechanism outside of Active Directory to set up user accounts for users not in Active Directory.
To help identify which authentication provider to use when assigning permissions or logging in, K2 blackpearl attaches a Security Label to the identity to associate specific credentials with a specific authentication provider. For example, the K2 SQL Provider uses the label K2SQL; the Active Directory Label uses the K2 prefix as the Security Label.
See Chapter 17 for more information on the administration of the security providers included with K2 blackpearl.
Additionally, K2 blackpearl is also designed with an extensible pluggable provider model for adding custom user and role providers. This allows flexibility for organizations that need to build or have already built custom authentication or are using an extensible third-party authentication system other than Active Directory. In these situations, a custom provider can be developed and plugged into K2 blackpearl to support other authentication mechanisms. These providers will use a unique security label to identify their use in the environment.
See Chapter 17 for information on the building custom security providers for K2 blackpearl.
The K2 Workspace is a Web-based interface for K2 server Management. Access to the workspace should be granted based on the principal of least privilege.
By default, all areas of the Workspace are viewable by all users within the domain. To keep the administration overhead for the K2 Workspace permissions low, one approach would be to create a domain group for permissions in the K2 Workspace.
Navigate to the Workspace Permissions by clicking on the Security menu and selecting Workspace Permissions, as shown in Figure 16-4.
Figure 16-5 shows the left side menu where there is a list of the Workspace Components for which permissions are granted.
These items correspond with the top K2 Workspace Navigation Bar (see Figure 16-6).
The following table shows an example of a quick and easy way to setup the K2 Workspace Permissions:
K2 Workspace Permission | Domain Group |
|---|---|
Reports | K2WorkspaceReports |
Management | K2WorkspaceManagement |
Notification Events | K2WorkspaceNotification |
Security | K2WorkspaceSecurity |
Then add the domain groups and/or users using Active Directory Users & Computers that will need access to the required areas of the K2 Workspace.
Note
By default, the Workspace Security list has no users. When this list is empty, K2 allows full access to the Workspace Security Permission. Once one user has been granted the Workspace Security Permission, all other users are locked out of the Security menu from within the K2 Workspace. Take care to include the K2 administrators first, than additionally add any additional users, if appropriate. The same rule applies to the Reports, Management Console, and Notification Events Security Permissions as well.
The K2 Management Console is the primary interface for managing the K2 blackpearl server. This chapter will only cover the configuration options relating to Rights, Permissions, Users, and Roles. For in-depth coverage of the K2 Management Console, see Chapter 20 on the K2 Workspace and reporting.
The K2 server Rights (see Figure 16-7) provide an interface to add rights for K2 administrators, grant permissions for process designers, developers, and deployment users to export processes, and grant permission for users to impersonate other users.
Right | Description |
|---|---|
Admin | This right allows the user to manage all aspects of the K2 Management Console; it also allows the repairing of processes, access to the reports, processes, and process instance data, and more. If it's in the K2 Workspace, the Admin right should grant access to it. |
Export | Users with this right can deploy processes and SmartObjects to the K2 blackpearl server. |
Can Impersonate | This right allows users to take actions on events within K2 blackpearl on behalf of another user. |
The ability to impersonate another user is an important privilege within K2 blackpearl. For example, the SharePoint Service account needs to do things on behalf of SharePoint users, so it requires the right to impersonate a user to properly carry out its work on behalf of that user. Additionally, the Impersonate Right is also often required for server events that need to impersonate users to accomplish some task. Grant this privilege with care, as impersonation has the potential to violate CIA and AAA.
Process Rights (see Figure 16-8) grant users the ability to participate within a workflow.
The following table shows the five Process Rights. These rights are set on a per-process basis:
Permission | Description |
|---|---|
Admin | Grants all of the rights below. Additionally is allows the management of the processes in the K2 Management Console. It also grants the ability to repair processes. |
Start | Start a new instance of the process. |
View | Allows the user to view any process instance for the process the permission is granted for, enabling reporting on the process in the K2 Workspace. The user is not able to participate in the process itself. |
View Participate | Allows a participant in the process, for example, the user is defined as the destination user for one of the process activities, to view the details of the process instance. The user will only be able to access process reports and the activity instance once it has reached the activity for which they are a destination user. |
Server Event | Asynchronous server events wait for a call-back from the external system to finish the server event. The user account used by the external system must be granted Server Event permissions for it to be allowed to finish the server event. |
Each process allows specific rights to be assigned for each action that limit a user's interaction with activities or client events within an activity. These are called Process Action Rights (see Figure 16-9).
The following table describes the different Action Rights:
Action | Name |
|---|---|
Allow | Allows the associated User/Group to view the activity or client event. |
Denied | Prevents the associated User/Group from accessing the activity or client event. |
K2 server Roles (see Figure 16-10) allow the ability to create a server-level dynamic container of users that can be resolved at design time or at run time. These roles can then be assigned within a process (see Figure 16-11) to control different actor's roles within the workflow.
Take care when setting the role refresh interval. The interval sets the time interval that these roles will be repopulated with current account information from Active Directory. If the time interval is set too long, the accounts could become stale, and users that have been revoked access may still have access causing a breach in confidentiality, or new users that need access to the system won't have access affecting availability.
The Environment Library provides a flexible way to create and store environment specific settings, for example, connection strings, server names, configuration options, for use in multiple environments such as development and production.
See Chapter 15 for more specific information on the Environment Library.
The Environment Library templates can potentially contain sensitive information like server names, server usernames and passwords so it's important to apply the principal of least privilege when granted access to these settings. See Figure 16-12 for the Environment Library Template Security settings.
There are two Template Actions associated with the Environment Library Template Security listed in the following table:
Template Action | Description |
|---|---|
Read Only | Allows users to view the environment template settings. |
Modify | Grants users permission to modify the environment template settings. |
Note
By default, the Environment Library Template Action List is empty. When the list is empty, K2 will allow full access to all users to the Template Library Templates. Once one Template Action is granted to a user, all other users are locked out of that template from both the K2 Object Browser as well as the K2 Management Console Environment Library Template settings. Take care to include the K2 administrators first, then add the appropriate users. Make sure that at least one user can make changes by granting them the Modify permission.
Grant the developers and workflow designers, at minimum, the Read privilege to any Environment Library Templates that store environment information supporting the development environment they work with. Architects or developers who are in charge of designing and configuring the Environment Library Templates should be granted the Modify right for the development environment templates. If there are multiple environments for different projects under development, it is appropriate to partition those into different Environment Library Templates as well and only grant developers and process designers working on a specific project access to the corresponding Environment Library Templates.
For review/test environments, depending on how the organization is structured, test engineers may be responsible for configuring the review/test environment templates.
Finally, production environments should be set up and configured by the K2 server administrators who are responsible for supporting the production environment. Developers and test engineers should not have access to read or modify the templates on the production server, as an incorrectly configured environment template could potentially cause data integrity issues or availability issues.
SmartObjects have the ability to pull data from disparate systems and make them available through a common interface to K2 blackpearl processes or the .NET Data Provider for K2 SmartObjects. There are two global SmartObject permissions (see Figure 16-13):
The following table defines each one:
Action | Description |
|---|---|
Publish SmartObject | Gives the specified user permission to publish a new SmartObject to the server. |
Delete SmartObject | Gives the specified user permission to delete a SmartObject. |
Apply the principal of least privilege to SmartObjects. On production servers, the ability to publish, and especially, delete SmartObjects should be granted judiciously.
SmartBox is the built-in SmartObject repository for K2 blackpearl that allows rapid development of data storage containers that are made available to processes and programmatic access via ADO.NET. For complete coverage of SmartBox, see Chapter 7. Figure 16-14 shows the security settings for any SmartBox object.
The following table lists and defines the permissions:
SmartObject Permission | Description |
|---|---|
Create | Allows users or groups to Create a new record. |
Save | Allows users or groups to Save changes to a record. |
Delete | Allows users or groups to Delete a record. |
Load | Allows users or groups to Select one record. |
Get List | Allows users or groups to Select a list of records. |
Modify Object | Users or groups can modify the SmartObject object definition. |
Most of the permissions listed in the table above govern the access control for who can access data in the SmartObject except the Modify Object permission. The Modify Object permissions allow changes to be applied to the SmartObject. Grant Modify Object permission with care on production servers as it can allow for the destruction of data.
The EventBus provides K2 blackpearl and API programmers the capability to fire events that are triggered based on various types of schedules (for example, a specific date and time has elapsed) or specific events (for example, a file in a folder being monitored has changed).
In order for new events to be registered within the Event Bus, a valid login is required to the K2 blackpearl server.
There are four interfaces that process designers use to develop new processes for K2 blackpearl:
Microsoft Visio 2007
Microsoft Office SharePoint 2007 (MOSS)
K2 Studio
Microsoft Visual Studio
Within these tools are two areas that security settings in K2 blackpearl govern:
The K2 Object Browser
The ability to export processes and SmartObjects
The K2 Object browser allows process designers and programmers to access only the working environments that they have been granted rights to view and/or modify. Additionally, there is the User Browser (which has no restrictions), process/activity data, and the Workflow Context Browser.
Security can and should be maintained on the Environment Library through the K2 Management Console. See the "Environment Library Templates Security" section earlier in the chapter.
Only developers and process designers with Export permissions can deploy a K2 process or SmartObjects to the K2 blackpearl server. All programmers and process designers who are responsible for building K2 processes and SmartObjects should have export permissions on the development K2 server. Without Export permissions it's impossible to push processes to the K2 blackpearl server and actually test and debug processes or SmartObjects.
It's important to go through and clean up processes that have been deployed on the development server from time to time, as they tend to become cluttered with unnecessary projects making it difficult to discern the actual projects vs. projects to be deleted. The development team should come up with a naming standard for process, so it can easily tell the difference between "real" projects and abandoned, test, or sample projects.
On the review/test K2 blackpearl server, limit users who can export projects, except a few appropriate users. Since this server is to look more like production, it will be helpful to limit access to make sure it stays organized.
Finally, on the K2 blackpearl production server, the approach taken for assigning permissions will depend on the security posture of the organization. Organizations with less stringent security posture should have only a few individuals with Export permissions on the production server, typically the lead and a couple alternates in the case of their absence. An organization with a stricter security policy will probably not allow the K2 process designers or programmers to have direct access to the production server (separation of duties), so the administrators in charge of the K2 server will need to have the ability to Export and be trained on the process or, instead, the developers will be required to deliver the K2 MSBUILD packages for the processes and SmartObjects. See Chapter 10 for in-depth information on how to create MSBUILD packages for deployment. There should be a test procedure set up in review to test the deployment packages before they are deployed on production.
Enabling remote server debugging on a K2 blackpearl server can be an incredibly useful tool; however, on a production server this can open it up to serious security issues. Resist enabling debugging on a production server. If it's deemed necessary, at least be willing to configure it only when it's needed. When debugging is not in use, make sure to disable it.
Every organization that does software programming needs to subscribe to certain security coding best practices. Here are some areas for further consideration and research:
Pay attention to the Open Web Application Security Project (OWASP) Top 10. It documents the most common vulnerabilities, including SQL Injection, Cross Site Scripting (XSS), Cross Site Requires Forgery (XSRF), and more.[20]
Use tried and true industry accepted vulnerability mitigation techniques. Don't invent mitigation techniques; it can be challenging to understand every angle of a security vulnerability and protect against them all.
Get training on secure programming that targets the programming language used by the organization's development team.
Code review; consider both Static Code Analysis products as well as peer review.
Follow industry and organizational best practices on handling sensitive data or classified data.
Adopt a form of the Security Development Lifecycle developed by Microsoft. (A good resource for looking into this is The Security Development Lifecycle by Michael Howard and Steve Lipner [MS Press, 2006]).
This is not a topic to take lightly. Even with the best security policies, system hardening, and security practices, it takes only one security vulnerability in code to put an entire organization's assets at risk.
It you decide to take securing the K2 blackpearl server seriously and work to apply the principal of least privilege to the K2 service account, you will most likely run up against some security issues that affect the functionality of the K2 server. For instance, perhaps the Host Service won't start, or perhaps the K2 Service crashes when a certain event happens on the server or certain functionality of the K2 Workspace doesn't function properly. These events may be evidence of a bug or an untrapped error in K2 server, but usually are caused by a failure to grant the K2 Service enough rights or privileges to function properly. Resolving these security issues can sometimes be a challenging task, this section covers concepts that will help with troubleshooting. Some of these are pretty obvious, but they are often overlooked.
Enable the Audit Policy in the Local Security Policy, and then turn on File auditing as well as Registry auditing in Windows for all failed attempts to access files and Registry data. This is a critical first step in troubleshooting issues related to accessing files/folders and for common Registry keys (HKLMSoftware and HKLMSecurity). This will reveal when the K2 Service account or a user can't access something on disk when it needs to. Figure 16-15 shows how to configure auditing of any failure to access a file or folder on the entire C drive for any user. The Failures will show up in the Security Event log.
To enable logging for a drive:
Right-click the drive and click Properties.
Select the Security Tab.
Click Advanced.
Select the Auditing tab.
In the entry box, type Everyone and click OK.
In the Auditing Entry for Local Disk (C:) dialog (see Figure 16-15), click the Full Control checkbox in the Failed column, which will automatically check all of the items.
Click OK.
Repeat this for all Drives installed in the system. Additionally, follow the same process for auditing all failures for HKLMSoftware and HKLMSystem nodes using the Registry Editor (regedit.exe).
Review the Windows Application, Security, and System Event logs. Additionally, enable and review specific server log files (for example, K2 blackpearl, Microsoft Office SharePoint, SQL 2005 Reporting Services, and SQL Server 2005 all have different logging mechanisms).
See Chapter 19 on logging and system reporting for more information on logging options for K2 blackpearl.
Stop the K2 blackpearl Service, and start up K2 blackpearl in Console mode. Console mode provides real-time logging feedback from the K2 server. The data will be similar to what is output in the K2 Log files, but can be tuned to provide a different level of logging by editing the HostServerLogging.config file located in the [K2 Install Path]K2 blackpearlHost ServerBin folder.
See Chapter 19 on logging and system reporting for more information.
If adding the K2 blackpearl Service account to the Administrators' group and cycling the K2 blackpearl Service seems to fix issues with K2 blackpearl, then chances are there is a right or privilege that has not been granted to the service account. Adding the account to the Administrators' group will prove this theory, but under NO circumstances leave the account in that group. Once you have narrowed it down to a security issue, then that limits the solution to a handful of items that are causing the issue. Review and audit file system and Registry permissions, the Local Security Policy privileges, and the log files to see if it reveals the access that is being denied.
If the previous tools aren't providing enough insight, Microsoft provides some more advanced tools like NetMon 3, Process Monitor, and Process Explorer to name a few. These aren't for the inexperienced, as understanding the output and knowing which false positives to ignore takes some experience and expertise. Most often than not, File and Registry auditing and reviewing log files will reveal what the issue is; however, occasionally I've found these tools helpful for getting to the root of an issue.
Hopefully, this chapter has expanded some views on information security and challenged others to raise the bar in securing their business and IT infrastructure. It's not an easy task, but it does become easier with practice. System administrators who persevere and work through the task of securing systems will not only learn more K2 blackpearl and Microsoft technologies but will also be better at troubleshooting operating system software configuration and security issues in general. Business owners who persevere by making information security a core tenant of doing business should rest easier knowing they have done more to protect the business, their employees, and customer data from harm.
The next chapter will explore how to administer and configure the default provider that ships with K2 blackpearl, called the Active Directory User Manager provider. Additionally, it will cover how to create, debug, and install custom Security Providers that plug into the Security Framework. Finally, the chapter will cover additional security provider features like Single Sign-On and new providers that will be available from K2 in the future.
[14] The Web Hacking Incidents Database Annual Report 2007 from Breach Security. https://bsn.breach.com/downloads/whid/The%20Web%20Hacking%20Incidents%20Database%20Annual%20Report%202007.pdf (You will have to register for free access.)
[15] "A Qualitative Risk Analysis and Management Tool — CRAMM" by Zeki Yazar, © 2002, SANS Reading Room. http://www.sans.org/reading_room/whitepapers/auditing/83.php
[16] "How to Conduct a Risk Analysis" by Shon Harris, © 2006,SearchSecurity.com. http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci1178862,00.html
[17] Definition for security policy, © 2003-2008,SearchSecurity.com. http://searchsecurity.techtarget.com/dictionary/definition/what-is-security-policy.html
[18] "A Short Primer for Developing Security Policies" by Michele D. Guel, © 2007, The SANS Institute. http://www.sans.org/resources/policies/Policy_Primer.pdf
[19] "Information Security Policy — A Development Guide for Large and Small Companies" by Sorcha Canavan, © 2003; 2006, The SANS Reading Room.http://www.sans.org/reading_room/whitepapers/policyissues/1331.php
[20] OWASP Top 10 2007, © 2007 OWASP Foundation. http://www.owasp.org/index.php/Top_10_2007