Recommended
More Related Content
What's hot
What's hot (20)
Similar to Operational Security 3.7
Similar to Operational Security 3.7 (20)
More from StephenKardian
More from StephenKardian (15)
Recently uploaded
Recently uploaded (20)
Operational Security 3.7
- 2. Operational Security • Understand Neuron ESB Runtime Security • Understand Topic Transport Level Security • Understand Neuron ESB’s Security Repository Goals
- 3. Operational Security • Neuron ESB Runtime; considerations and deployment • Topic Transport Security for both MSMQ and RabbitMQ • Creating security items in the Neuron ESB Security Repository • Accessing encrypted values in Code Editors Lesson Plan
- 4. Operational Security Neuron ESB Runtime Neuron ESB Runtime • Default service account is Local System • All Endpoint Hosts inherit the service account assigned to Neuron ESB Runtime Problem • Local System has full Administrative rights on the box • Anything running within the Neuron ESB Runtime has full access to everything that Local System does • Adapters • Services • Business Processes • Workflow • Custom .NET Assemblies
- 5. Operational Security Neuron ESB Runtime Change service account • Local user or domain user • Use Service Control Manager Permissions and Groups • Must have Log on as a Service right • Must be in Performance Monitor Users group • Grant specific rights as needed to access local or remote resources • Must have rights to the Neuron ESB Solution folder • Must have rights to the Temp folder the instance is configured to use
- 6. Operational Security Deployment Considerations • TCP Port Sharing Enabled • Must modify AllowAccounts section of SMSvcHost.exe.config or Neuron ESB Runtime will not start • https://www.neuronesb.com/article/port-sharing/ • Windows Management Instrumentation (WMI) Events • May have to manually install WMI Events • Use PowerShell script: C:Program FilesNeudesicNeuron ESB v3PowerShellRegisterWmiEvents.ps1 • HTTP based (REST/SOAP) Service Endpoints • Client Connector URLs must be manually registered (once) • Use netsh command e.g. netsh http add urlacl url=<url> user=<computer/domain-name><username> Neuron ESB Runtime
- 7. Operational Security Deployment Considerations • May need elevated rights to access third party systems • Adapter Endpoints • Supports RunAs • Neuron ESB Runtime Service Account needs delegation/impersonation rights • Service Endpoints • Uses ACLS/Credentials to access secure service Neuron ESB Runtime
- 8. Operational Security : Demo Purpose: To familiarize users with how to configure the Neuron ESB Runtime to use a Least Privilege service account Objectives: To acquaint users with the following: • Changing the service account of the Neuron ESB runtime • Adding necessary groups and permissions to user account
- 9. Operational Security Topic Transport Security MSMQ • Durable Transport for Neuron ESB Topics • Supports Certificates/Signing/Encryption • Created through Neuron ESB Explorer or generated PowerShell scripts • PowerShell Scripts apply default permissions on Queues Permissions • By default, ALL the queues that Neuron ESB requires for MSMQ-based Topics are configured with following permissions: • Everyone - Full rights • Anonymous Logon - Full rights
- 10. Operational Security MSMQ • Permissions • Applied to Neuron ESB Service Account • Delete • Receive Message • Peek Message • Get Properties • Applied to the Anonymous Login (if MSMQ is remote to Neuron ESB Server OR remote parties are used) • Send Message • Applied to user accounts running Remote Parties • Peek Message • Receive Message • Delete • Get Properties Topic Transport Security
- 11. Operational Security Topic Transport Security RabbitMQ • Durable Transport for Neuron ESB Topics • Supports SSL and Client Authentication using Certificates • Requires Access to RabbitMQ Management Portal Permissions • By default, Management Portal access uses Guest account
- 12. Operational Security Neuron ESB Solution Security Repository • Credentials • Certificates • Username/Password • Windows Credentials • Access Control Lists • Encryption Keys • OAUTH Providers
- 13. Operational Security Neuron ESB Solution Security Repository • All Sensitive Information is Encrypted on disk • Passwords • Pass phrases • Encryption Keys • Access Tokens • Client Secrets • Consumer keys • Etc.
- 14. Operational Security Neuron ESB Solution Other Entities • Database Connection Strings • Adapter Endpoint Configuration • Anything using PasswordPropertyText attribute (e.g. database connection strings, passwords) • Examples: • Salesforce • ODBC • FTP/SFTP • NetSuite • Custom Adapters • Business Process Step Configuration • Environmental Variables Values • Topic Transport Configuration • Basically anywhere we want
- 15. Operational Security Neuron ESB Solution Accessing Encrypted Values • Business Processes • Workflows • Custom Adapters • Custom Process Steps • Custom Workflow Activities Why? • To dynamically configure security elements at runtime
- 16. Operational Security : Demo Purpose: To familiarize users with how to access encrypted values in Neuron ESB Objectives: To acquaint users with the following: • Access encrypted values in Business Processes • Access encrypted values in Workflows • Access encrypted values in .NET applications
- 17. Operational Security Neuron ESB Database Neuron Database Permissions • Neuron ESB Explorer • Use only for development instances of the Neuron ESB database • Need dbcreator or sysadmin permissions on SQL server • Neuron ESB SQL Scripts • Need dbcreator or sysadmin permissions on SQL server • Use for environments higher than development • <Neuron Install Directory>Neuron ESB v3Sql • Adding a user to the Neuron ESB database • Need to be part of the neuronusers database role
- 18. Operational Security : Demo Purpose: To familiarize users with how to configure the Neuron ESB Database Objectives: To acquaint users with the following: • Database Security
- 19. Operational Security Review • When configuring a least privilege service account for the Neuron ESB Runtime, what groups must the user account below to? • What rights must be granted to the Neuron ESB Runtime service account? • When running under a least privilege service account what must you do at least once to ensure that HTTP based client connectors start up? • When running under a least privilege service account, you find that your custom application is no longer receiving WMI events from Neuron ESB. What can you do to attempt to correct? • What rights does the service account need to run an Adapter Endpoint under a different set of credentials? • The Neuron ESB fails to start because the service account doesn’t have access to the Neuron ESB database. How can you correct this? What security group is used? • How can you provide read only access to the Message History report to a group a users? • What can be used to automate setting MSMQ based security permissions required by Neuron ESB? • Using the Guest account to access RabbitMQ on a remote machine results in an Unauthorized error. What must you do to correct? • Where can you view the encrypted password for a Security Credential created within the Neuron ESB Explorer?
Editor's Notes
- The goals of this lesson are to provide users with an understanding of Neuron ESB runtime security, topic transport level security and the Neuron ESB Security repository.
- To facilitate our goals this lesson has been broken down into four sections to make the information provided easier to understand. The sections what we will be covering are Neuron ESB Runtime; considerations and deployment Topic Transport Security for both MSMQ and RabbitMQ Creating security items in the Neuron ESB Security Repository Accessing encrypted values in Code Editors
- The Neuron ESB Runtime uses the Local System service account by default. However, using the Local System account comes with a number of problems such as the fact that it has full administrative rights on the machine. This means that not only does the Neuron ESB Runtime receive full administrative rights on the machine, but so to do all the entities that inherit the Neuron ESB runtime service account. Adapters Services Business Processes Workflows Custom .NET Assemblies
- It is possible to change the user under which the Neuron ESB runtime operates, either during installation or by using the Service Control Manager. However, in doing so it is important to ensure that the new service account has the appropriate permissions necessary for Neuron ESB to function properly. Any account under which the Neuron ESB runtime operates needs to have Log on as a Service rights. It must be part of the Performance Monitor user group. You will need to make sure that it has specific rights to access local or remote resources as required by your solution. It must have rights to access the Neuron ESB solution folder, as well a the Temp folder that the instance is configured to use.
- Other things to take into consideration when changing the service account under which the Neuron ESB runtime operates are some deployment considerations. If TCP Port Sharing is enabled you will need to modify the AllowAccounts section of the SMSncHost.exe.config file to allow the new service account or else the Neuron ESB runtime will not start. If you select a different service account when installing Neuron ESB you may need to manually install WMI events, if the selected account does not have sufficient permissions to do so. This can be done by running the RegisterWmievents PowerShell script provided to you by Neuron ESB. It may also be necessary to manually register client connector URLs using the provided netsh command.
- If you do not wish to grant the Neuron ESB runtime permissions which allow it to access third party systems, you will need to ensure that adapter endpoints are run, using the RunAs property, under an account with the appropriate permissions to access the systems required. This will require the Neuron ESB runtime service account to have delegation and impersonation rights as well. For service endpoints you will need to make use of access control lists and client credentials to allow access to and from secure services.
- In addition to permissions necessary for the Neuron ESB runtime to operate there are considerations to be made in regards to MSMQ. By default Neuron ESB creates MSMQ queues with permissions granting everyone, including anonymous logon, full rights.
- If you wish to change this, so that not everyone has full rights to the MSMQ queues, you will need to ensure that certain minimum permission requirements are met. The service account under which the Neuron ESB runtime operates will need to have the rights to Delete, Receive Message, Peek Message and Get Properties. If MSMQ is located on machine remote to the Neuron ESB installation, or remote parties are being used in your solution, then Anonymous Login will need the Send Message right. Any user accounts that are running remote parties (think .NET application using the Neuron Client API) will need to be granted the same permissions as the Neuron ESB runtime account.
- Rabbit MQ is another area in which you may need to make some changes to permissions and accounts. By default RabbitMQ uses the guest account as its administrative account. The guest account is limited in that it cannot access remote installations of RabbitMQ. To address this you will first need to install the RabbitMQ Management Portal (https://www.rabbitmq.com/management.html). This will allow you to create a new administrator account which has permissions to access remote instances of RabbitMQ. Once you have created a new administrator account, you need to instruct Neuron ESB to use that account when interacting with RabbitMQ. This can be done on the RabbitMQ tab of each Deployment Group.
- The Neuron ESB Security Repository is where you can manage and create Credentials for use in conjunction with client and service connectors, Access Controls Lists for use in conjunction with client connectors, Encryption Keys which can be used to encrypt values within Neuron ESB and OAuth providers for use in conjunction with service connectors.
- Entities created in the Security Repository will have all of their sensitive information encrypted when written to the Neuron ESB files located on the file system. This includes any passwords, pass phrases, encryptions keys, access tokens, client secrets, consumer keys etc…
- Not only are the values of Security Repository entities encrypted on disk, but many other values also get encrypted before they are written to disk. Database connection strings, various aspects of adapter endpoints such as the password property text, client secrets and access tokens (think salesforce adapter), business process step configurations, environmental variable values, pretty much anything we feel might compromise the security of the solution.
- While values for entities are encrypted in the Neuron ESB files, it is possible to access these values in business processes, workflows, custom adapters, custom process steps and custom workflow activities, should users need to dynamically configure the security elements of ant of these entities at runtime.
- Creating the Neuron ESB database can be done either via the Neuron ESB Explorer or through the use of the SQL scripts provided with Neuron ESB. Creating the database using the Neuron ESB Explorer is recommended only for creating the development or local system database as the credentials that the explorer is operating under needs to be either a dbcreator or sysadmin on the SQL server machine, something that most developers are not. It is recommended that the Neuron ESB database scripts are used to create databases in environments higher than development, as this is usually performed by a DBA or someone with the appropriate permissions to do so. Adding a user to the Neuron ESB database, such as adding the service account under which Neuron ESB is running, requires that the user be part of the neuronusers database role.