Application Security on Cloud is an application security offering that allows you to scan on prem, web, and mobile applications for security vulnerabilities. The ASoC plug-in allows you to run all supported types of scans and manage ASoC presences. Presences allow you to run scans on apps not connected to the internet or require a proxy server to make a connection.
IBM UrbanCode Deploy’s security systems are well-documented in the product’s Knowledge Center. However, there are many interlocking systems which can make finding information a bit of a slog. The white paper, IBM UrbanCode Deploy security features, brings all of the security-related systems together in one place.
The paper surveys all the product’s security systems with special emphasis on server-agent communications. Some of the paper’s topics include:
server-agent communications including end-to end JMS encryption
agent verification of server certificates
UrbanCode Mobile security
team- and role-based security model
key stores and trust stores
supported TLS protocols
The PDF version is thoroughly indexed for ease of use.
With a new version of IBM Bluemix DevOps Connect published, it’s a good time to review the product’s architecture and security features.
IBM Bluemix DevOps Connect, formally named UrbanCode Sync, is a free utility that provides on-prem UrbanCode product data to the IBM cloud services. The first version, released last summer, provides IBM UrbanCode Deploy and IBM UrbanCode Release data to UrbanCode Mobile users. UrbanCode Mobile users can review deployments and make approvals with their mobile phones or other devices.
IBM Bluemix DevOps Connect is typically installed in the same location as your on-prem UrbanCode products. You run integrations with your on-prem products from the IBM Bluemix DevOps Connect web-based dashboard. You configure integrations in the same manner as you configure integrations with IBM UrbanCode Deploy and IBM UrbanCode Release. The plug-ins that you need to integrate with UrbanCode Mobile comes pre-installed. You can install new plug-ins in IBM Bluemix DevOps Connect as they become available.
The IBM UrbanCode Cloud Services Security white paper reviews the product’s security features. The topics covered include the following features:
What data is exchanged with the cloud?
How trust is established
How users are authorized
How approvals and tasks are secured
How data is secured
The following diagram–excerpted from IBM UrbanCode Cloud Services Security–illustrates the architecture of IBM Bluemix DevOps Connect.
IBM Security Access Manager enables businesses to more securely adopt web, mobile, and cloud technologies and simplifies user access management for employees and consumers. It simplifies and secures user experiences with single sign-on across applications and protects critical assets using strong multi-factor authentication and risk-based access. It also enables the mobile enterprise with mobile access control policies that integrate with mobile device management, mobile application development and malware detection solutions. Furthermore, it helps bridge the access control gap between on-premise and cloud environments.
This community supported plug-in will update a Reverse Proxy’s configuration entry.
IBM AppScan Enterprise enables organizations to mitigate application security risk and achieve regulatory compliance. This plug-in includes steps to run AppScan Enterprise scans and retrieve scan results in IBM UrbanCode Deploy processes.
Configure Job Options: Configure scan job options. Create Scan: Create an AppScan security scan. Delete Folder Item: Delete a folder item, such as a Scan or Report, from the AppScan Scans view. List Templates: Retrieve and print a list of available job templates. Retrieve PDF Report: Retrieve report from AppScan Enterprise. Reports are saved as a PDF file named [reportFIID]-[date]-[time].txt Retrieve Reports: Retrieve reports from AppScan Enterprise. Run Scan: Run an AppScan security scan. Wait for Scan or Report Pack: Wait for an AppScan Scan or Report Pack to complete.
Supports IBM Security AppScan Enterprise version 9.0.3 and greater.
AppScan’s webhook functionality will call the specified REST API endpoint with given payload and Basic authentication following the completion of a content scan job. A hidden field has been added to the `Create Scan` step to configure the webhook. Learn more about the webhook functionality here.
The webhook beta functionality was added in IBM Security AppScan Enterprise version 188.8.131.52.
The team-based and role-based security model in IBM UrbanCode Deploy v6.x can be described as slightly intricate. Its intricacies give it the flexibility and capability to satisfy a broad range of requirements though. This guide is an outline of how to configure the security model in core UrbanCode Deploy. It is supplemental to the Knowledge Center’s description of Deploy’s security model. My intent is to give direction on how to adapt the model based on individual requirements, so please share your comments, questions, and feedback so I can continuously improve the guide.
The content in this post revolves around these items, which are all visible in UrbanCode Deploy on the Settings tab:
This post deals with the items in this list (excluding Tokens).
Getting Started with LDAP/SSO
Immediately after installation of the server, the only available ID for use is the default administrator ID (admin). This password is set during the server installation process. Most organizations will then opt to configure LDAP or SSO as an Authorization Realm and Authentication Realm in the tool. An authorization realm in UrbanCode Deploy is used to search for an ID and determine which groups it belongs to. An authorization realm works in conjunction with an authentication realm, which is used to confirm a user’s identity upon login using a password. With both realms defined, there is no need to manage user IDs and group membership in the tool outside of an existing corporate directory. When properly configured, users can login to UrbanCode using their existing corporate credentials, and any applicable groups/IDs will be auto-imported as needed. Most importantly for this portion of the setup is to engage an LDAP/SSO administrator ahead of time, in order to figure out all the connection details and search strings which are needed. The administrator should also be available while testing the configuration.
Integrating UrbanCode with LDAP is arguably the easiest part of the security configuration. Next we come to Teams and Roles. Keep in mind that UrbanCode Deploy is an enterprise-class solution, purposefully built to scale and enablement self-serve deployments for all applications/teams in the organization. From a hierarchical perspective, teams and roles are at the top of the security model so if these are not defined carefully, it can make things difficult in the future.
Every team in UrbanCode Deploy (a “System Team” exists by default) has all roles available to it. The tool assumes common roles across your application development teams, but it doesn’t require any role to be filled. While planning, think of teams and roles in the context of the entire organization. Ask yourself these questions:
What application development teams exist across my organization? Do an assessment if that is what’s required to answer this question.
What are some of the common roles that are played in application development teams across the company? In most cases, there are developers, testers, release engineers, DBAs, stakeholders, and operations/production support engineers. There may be others in your organization.
Does my organization want to centrally manage application deployments and the underlying processes, or allow the development teams to manage this themselves? This will naturally impact how permissions are granted to various roles. Most organizations with a central DevOps strategy will predefine all deployment processes using templates. Think about how much freedom you can afford to grant to your development teams, and the pros and cons of doing so.
What permissions should be granted to a stakeholder versus a developer or a production support engineer, for example? Confer with key stakeholders and decide what permissions should be granted to each role. For example, developers may have the ability to create new components and applications from a template and deploy at will to upstream development and test environments, but perhaps they shouldn’t be able to deploy any applications to more stable environments such as SIT or UAT. Support engineers may not be given permission to create new components or applications at all, nor edit the processes associated with them, but they may have the ability to deploy existing applications to more stable environments. This list goes on.
You may find the need to create very similar but slightly different roles to accommodate how different teams work in your organization. You may also need to look closely at the application development teams you have identified and see if it makes sense to decompose any of them into smaller teams. Whatever the case, once you reach a consensus about teams and roles, document the information and review it again before implementing anything in the tool.
Creating Teams and Roles, and Setting Permissions on Roles
Defining new teams in the tool is pretty simple. Click a button, pick a name, and save. Defining new roles and setting the correct permissions for each is a bit more involved. By default, new roles that are created have no permissions at all. The only role that is predefined in UrbanCode Deploy is the Administrator role, which has all permissions. Also, recall that users and groups can have different roles on different teams.
The UrbanCode Deploy Knowledge Center provides a complete reference for permissions. Spend an hour or two familiarizing yourself with the permissions that are available and what they mean. This is a prerequisite to participating in the discussion about how to grant permissions to various roles. A useful approach for deciding which permissions to grant to each role is to use a spreadsheet or even a checklist that contains all the items listed in the reference. For each role, run through the complete list of items and use a highlighter to indicate the permissions that should be granted to that role. Once you have repeated this process for all roles, review the results as a team before implementing it in the tool.
If you are going to use Security Types in the tool (see next section), include this in your discussion about permissions before doing any implementation.
Using Security Types
UrbanCode Deploy distinguishes between object types and security types. There are ten distinct object types (listed vertically in the next screenshot). Object types can have multiple security types, which allows administrators to set different permissions on object types based on security classification. For example, take the “Environment” object type. Administrators can create additional security types beneath this object type to set different permissions on DEV environments versus QA or PROD environments. This works similarly for agents, components, templates, or other objects. A default security type called “Standard” exists for all objects and cannot be deleted. New security types can be created for each object type using the “Type Configuration” sub-tab (on the Settings page):
Use security types to set more granular permissions on objects based on security classification.
Once additional security types have been created, they are visible on the “Role Configuration” sub-tab, which is where permissions are configured.
It is sometimes useful to define a separate role called “Team Lead” (or something similar) if there will be someone other than Administrator managing users and roles for any team. With this approach, the primary Deploy administrators do not have to get involved with managing individual team membership. The key difference between Team Lead and the Administrator role is the “Manage Security” permission under Server Configuration. Users with the “Manage Security” permission in UrbanCode Deploy can grant themselves any additional permission they want. Effectively, the “Manage Security” permission allows users to do ANYTHING in the tool, so the Team Lead role is also used to limit the number of users with that permission. The “Add Team Members” permission should remain enabled for the Team Lead role:
Team Leads can have all permissions except “Manage Security” which should be saved for Administrators only.
In order for Team Leads to manage team membership without the “Manage Security” permission, they must click their username in the top-right of the web UI and select My Profile → My Teams:
To manage teams without the Settings tab enabled or without the “Manage Security” permission, click My Teams.
The user acting as Team Lead should also be assigned to all other roles on the team (except Administrator), in order to be able to add/remove users or groups to other roles. This is really just a simplification exercise. UrbanCode Deploy will look at the permissions granted to each role and forbid the current user from managing roles which have more permissions than he/she does. In other words, if the Team Lead has less permissions than any other role you have defined, he/she will not be able to manage that role and Deploy will return an error if an attempt to do so is made. Thus, to simplify, the user acting as Team Lead should also be assigned to all other roles on the team (except Administrator).
Mapping Users/Groups to Roles
At this point in the configuration, the foundation of the security model is set. One of two important steps that remain is to build out the team by mapping users and/or groups to various roles. This is relatively straightforward. If there are groups in LDAP that align closely with the roles that have been defined in Deploy for a particular team, this may also go fairly quick. Map users and groups to a particular team by clicking “Add Users & Groups” on the Team sub-tab. This reveals a side-panel that allows Team Leads and Administrators to drag-and-drop new users/groups onto a role.
Team Object Mappings
Users and groups are mapped to roles in the context of a team. Team roles and security types determine what permissions are granted to a user/group. In addition to mapping users and groups to a role for every team, you must also map objects to each team. For newly created objects, users can set default team mappings by clicking their username and selecting My Profile → Preferences. If users do not set this preference, newly created objects will map to all teams for a user.
For existing objects in UrbanCode Deploy, these can be mapped to a team under the “Team Object Mappings” section on the Teams sub-tab. This requires the “Manage Security” permission:
Existing objects can be mapped to teams on the Teams sub-tab.
Select the object type using the View drop-down, then select a security type using the Type drop-down. Click Add to see a pop-up similar to the following:
This is the pop-up where additional objects can be mapped to the team.
This is a list of all available objects of the selected object type and security type that are not already mapped to the team. Select the objects you want to add and click OK.
Save the Administrator role for just a few users or a small group. There should only be a few roles which have the “Manage Security” permission. You do not need to fill the Administrator role on each team.
When mapping users/groups to roles, it is possible to shift some of this administrative overhead back to LDAP by maintaining separate LDAP groups for each role on each team. In UrbanCode Deploy, only a single group then is mapped to each role on a team.
In order to take full advantage of the team-based and role-based security model in Deploy, first decide which teams you are going to create. From a strategic standpoint, think specifically about what you want to get out of the tool. Take some time to carefully plan how you want to build your team structure, then think about what roles may exist on all of those teams. During this process, consult the Knowledge Center’s permissions reference to understand what permissions can be granted per role on various objects (and their security types). Remember that roles are common to every team in the tool but not all roles will be filled on each team.
Users and groups must be mapped to roles for every team. Integrating UrbanCode Deploy with LDAP allows organizations to leverage an existing corporate directory for user identity and group membership.
There are ten object types in the tool including applications, components, processes, agents, various templates, and others. Objects must be mapped to one or more teams in order for them to be used. Users should set default team mappings for newly created objects in their profile preferences.
New security types can be defined for each object type in UrbanCode Deploy. This will allow you to set different permissions on objects based on security classification (i.e. applications, agents, environments, etc. in PROD versus those in DEV).
Once again, if you have questions, comments, or feedback, please connect with me somehow. I am happy to engage in additional discussion on this topic.
IBM UrbanCode products use a role- and team-based security system. Permissions are assigned to roles, not to users. In IBM UrbanCode Deploy, for instance, roleless users can only access their user preferences.
Typically, when administrators set up security they also define roles and teams. An extremely useful role you can create is a Team Lead role. The Team Lead role can manage a team’s roster without further involvement from an administrator, or additional administrative permissions.
To test drive the role, create a role and name it Team Lead or something similar. Grant the Add Team Members permission from the Server Configuration area to the role, as shown in this figure. This permission enables users to manage their team rosters—add users to team roles, and remove users from their team. Users with this permission can manage the rosters of their own teams but not other teams.
Add the other permissions granted to team members. Do not add the Manage Security permission to the role. The Manage Security permission essentially creates an administrator-type role because it grants access to all security features, which is not what you want.
Users without the Manage Security permission cannot access the security options, but that’s fine. All users, even roleless users, can access their own My Team page. You do not need the Manage Security permission to view your teams.
You access your My Teams page from the My Profile menu, as shown in this figure.
The My Teams page lists the teams to which you belong—and no others. In this example, Demo User, user ID Demo, belongs to two teams—Demo Team and Demo2 Team. She is assigned to the Team Lead role for Demo Team, as shown in this figure. The Team Lead role enables her to delete users and add users to roles on the Demo Team. Even though Demo User does not have access to the system administration functions, she can act as team administrator by using her My Team page. If the Team Lead role did not have the Add Team Members permission, Demo User, like any other user, could review her teams but not modify them. The Add buttons would not be displayed.
What happens when a user is in the Team Lead role for some of their teams but not for others? As you would expect, a user without the Add Team Members permission cannot affect the team roster. In this example, Demo User is the team lead for Demo Team but not for Demo2 Team. If Demo User attempts to modify Demo2 Team’s roster, she is prevented and a message informs her that she does not have permission to change team membership.
Note: The UI can sometimes be slow to update, which can make it appear that an unexpected roster change occurred. If this happens, refresh the window.
Because all roles are available to all teams, the Administrator role, with all its privileges, are also available on the My Teams page. If Demo user attempts to add herself to the Administrator role for Demo Team, she is prevented even though she is the Team Lead. A user in a role with the Add Team Members permission cannot affect a role that has more permissions than the user with the Add Team Members permission. Because the Administrator role has more Server Configuration permissions than the Team Lead role, Demo user cannot add or remove users from the Administrator role.
To be effective, a team lead role needs, in addition to the Add Team Members, all permissions granted to roles the team lead is expected to manage. If you have team types with different permission sets, you might need several team lead roles–Development Lead and Production Lead, for example. The simplest solution is to grant all permission to the team lead role except those reserved for the Administrator role. Remember, users in lead-style roles can only affect the teams to which they belong.
Tip: User Preferences for Team Object Mapping
By default, the objects that you create are automatically mapped to the teams to which you belong. You can change this behavior with the Default Teams for New Objects parameter in your Preferences. Instead of all your teams, you can select a subset of them, or none at all.