Computers, Programming, Technology, Music, Literature

Azure AD – Adding EmployeeID claims in Azure AD JWT token

leave a comment »

This blog also appears at https://devonblog.com/author/inmaran/

First part of the blog – https://renouncedthoughts.wordpress.com/2018/10/30/azure-ad-viewing-active-directory-domain-services-synchronized-attributes-in-azure-ad/ 

The JWT token emitted by the Azure AD, irrespective of whether it is an access token, or an id token, does not contain much useful information except the email address and some other fields. Particularly when you are coming from an enterprise background where employee id plays a crucial part in identifying a user in a lot of backend systems, then we need more claims as a part of the JWT token apart from the default claims that are present in the JWT tokens. In this article, let’s look at the steps to include a custom claim, such as an employee id as a part of the JWT token itself. So when the JWT token is passed around to the backend services, the backend services could identify a user based on employee id and make necessary claims.

Prerequisite

Refer to the blog titles “Viewing Active Directory Domain Services’ synchronized attributes in Azure AD” (https://renouncedthoughts.wordpress.com/2018/10/30/azure-ad-viewing-active-directory-domain-services-synchronized-attributes-in-azure-ad/) to find out the actual name of the Azure AD attribute that needs to be a part of the JWT token. This article will focus on adding employeeid claim as a part of the JWT token, however the same can be applied to any other attribute in Azure AD that is synchronized from on premises Active Directory Domain Services (AD DS).

We are going to be using a the “Claims Mapping” feature of Azure AD that is currently in “public preview” at the time of this writing.

The documentation sometimes could be out of date or obsolete or sometimes just plain wrong. So in order to obtain the desired result it is recommended to follow the exact steps described in the article.

The sample application that we would be using to test whether the employee id is added as a part of JWT claims would be https://github.com/dream-365/OfficeDev-Samples. However if there is an existing application already registered under Azure AD à applications, then it should also work provided that edit the manifest file and configure the appropriate “Application ID” settings.

Since “Claims Mapping” is a public preview feature, there is no GUI support in Azure portal, and we would need an Azure AD powershell module that supports “Claims Mapping”. As recommended in the MSDN documentation, this particular version of Azure AD Powershell public preview – https://www.powershellgallery.com/packages/AzureADPreview/2.0.0.127 works with the samples as described in the article. The future releases of Azure AD Preview or the newer releases work as well.

Claims Mapping Policy

A Claims Mapping policy is a policy that would be associated to a Service Principal Object for an Application in Azure AD. A service principal is an identity that is used to run an Application in Azure AD.

[For example: Under services.msc in Windows, a service runs under an identity such as Local Service, or Network Service, or anything that is configured to run under. Similarly, every application that is registered in Azure AD, runs under it’s own service principal (synonymous to a service account in Windows / Linux )]

In the screenshot below, the Application ID and Object ID is not the Service Principal. We need Get-AzureADServicePrincipal cmdlet from Azure AD powershell to query the service principal id of an application.

image

image

Step 1: Edit the Application’s manifest to process claims mapping

Set acceptMappedClaims to true

{
  "appId": "9e96667b-………….",
  "appRoles": [],
  "availableToOtherTenants": true,
  "displayName": "Office365DevQuickStart",
  "errorUrl": null,
  "groupMembershipClaims": null,
  "optionalClaims": null,
  "acceptMappedClaims": true,
  "homepage": "http://localhost",
  "informationalUrls": {
    "privacy": null,
    "termsOfService": null
  },
  

image

Step 2: Understanding a Claims Mapping Policy and binding it to a service principal

This step is only to understand how Claims Mapping policy is created and how it is bound to a service principal object in Azure AD. Step 3 proposes a powershell script do all of this in one go.

So, Creating a New-AzureADPolicy to include employeeid is as below. Running this cmdlet would throw back an Object ID for the created Policy.

New-AzureADPolicy -Definition @('{"ClaimsMappingPolicy":{"Version":1,"IncludeBasicClaimSet":"true", "ClaimsSchema": [{"Source":"user","ID":"employeeid","JwtClaimType":"employeeid"}]}}') -DisplayName "ExtraClaimsEmployeeID" -Type "ClaimsMappingPolicy" 
  

Then with the created policy, we need to run the cmdlet below to associate it with a service principal. Service principal is obtained from the the Get-AzureADServicePrincipal cmdlet.

Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Policy> 
  

That’s all.

Step 3: Running the powershell script to create Claims Mapping policy and bind the policy to Application’s Service principal

The script below removes any existing policies bound to a Service Principal Object. If you don’t existing policy mappings to be removed, modify the script accordingly. But if you are creating claims mapping for the first time, then you could keep the script intact.

Replace the $appid with the Application ID value of the application

Save the below script as AddEmployeeIDToJWTClaims.ps1

Open powershell and run cmdlet Connect-AzureAD

Run AddEmployeeIDToJWTClaims.ps1

$claimsMappingPolicy = [ordered]@{
    "ClaimsMappingPolicy" = [ordered]@{
        "Version" = 1
        "IncludeBasicClaimSet" = $true
        "ClaimsSchema" = @(
            [ordered]@{
                "Source" = "user"
                "ID" = "employeeid"
                "JwtClaimType" = "employeeid"
            }
        )
    }
}

$appID = "9e96667b-d0......................" 
$policyName = "Add employeeid to JWT claims"

$sp = Get-AzureADServicePrincipal -Filter "servicePrincipalNames/any(n: n eq '$appID')"
 
$existingPolicies = Get-AzureADServicePrincipalPolicy -Id $sp.ObjectId `
                    | Where-Object { $_.Type -eq "ClaimsMappingPolicy" }
if ($existingPolicies) {
    $existingPolicies | Remove-AzureADPolicy
}
 
$policyDefinition = $claimsMappingPolicy | ConvertTo-Json -Depth 99 -Compress
$policy = New-AzureADPolicy -Type "ClaimsMappingPolicy" -DisplayName $policyName -Definition $policyDefinition
 
Add-AzureADServicePrincipalPolicy -Id $sp.ObjectId -RefObjectId $policy.Id
Write-Output ("New claims mapping policy '{0}' set for app '{1}'." -f $policy.DisplayName, $sp.DisplayName) 
  

image

Powershell script courtesy of http://www.redbaronofazure.com/?p=7566.

There you have it. That should have you get going with adding employeeid claims with AzureAD’s JWT token.

Step 4: Configuring a Proof of Concept Application to request a JWT token with employeeid claims

The steps below outline, what it takes to run the https://github.com/dream-365/OfficeDev-Samples as a proof of concept to visually see the employeeid added as a part of the JWT token.

The steps below outline, what it takes to run the https://github.com/dream-365/OfficeDev-Samples as a proof of concept to visually see the employeeid added as a part of the JWT token.

Open the Office365DevQuickStart.sln file in Visual Studio and navigate to the project OAuth2-basic.

Replace the values of the OAuthBasic.cs file as appropriate. For our example, here’s how the file was modified.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace OAuth2_basic
{
    class OAuthBasic
    {
        public void Run()
        {
            var oauth = new OauthConfiguration
            {
                Authority = "https://login.microsoftonline.com",
                Tenant = "common",
                ClientId = "9e96667b-………………", //application id
                RedirectURI = "http://localhost"
            };

            var flow = new AuthorizationCodeGrantFlow();

            flow.Go(oauth);
        }
    }
}
  

Open AuthorizationCodeGrantFlow.cs and modify code as below. Change the value of the resource to any resource in your tenant. If the application has permission to access the resource, and the user has given consent to allow an application to access the resource, our Claims Mapping policy would get applied and we would get a JWT token with the employee id. If not, try requesting a JWT token for the application id itself.

using System;
using Newtonsoft.Json.Linq;
using Newtonsoft.Json;

namespace OAuth2_basic
{
    /// <summary>
    /// Authorization Code Grant Flow
    /// https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx
    /// </summary>
    public class AuthorizationCodeGrantFlow
    {
        public void Go(OauthConfiguration oauth)
        {
            var auth = new OauthWebAuthHelper(oauth);

            var tokenResponse = auth.AcquireTokenWithResource(resource: "a58d4d7a-76…….. ");

            //ta2 app id// a58d4d7a-7649-…….
            //native app id// 9e96667b-d0f7-……..
            //var tokenResponse = auth.AcquireTokenWithResource(resource: "https://outlook.office.com");
            //var tokenResponse = auth.AcquireTokenWithResource(resource: "https://graph.windows.net/"); 
            var err = tokenResponse.GetValue("error");
            if (err != null)
            {
                err = tokenResponse.GetValue("error").Value<string>();
                var errdesc = tokenResponse.GetValue("error_description").Value<string>();
                Console.WriteLine("Error: {0} - {1}", err, errdesc);
            }
            else
            {
                Console.WriteLine("access token:");

                var accessToken = tokenResponse.GetValue("access_token").Value<string>();
                var validator = new JsonWebTokenValidator();
                var jwt = validator.Validate(accessToken);
                Console.WriteLine(JsonConvert.SerializeObject(jwt.Payload, Formatting.Indented));
            }

            Console.Write("Find the Any Key on your keyboard and hit it with all you got to continue...");
            Console.ReadLine();
        }
    }
}
  

Run the application, and follow the steps as below. We ran a fiddler trace as well to capture the http traffic and see the raw JWT token.

clip_image002

clip_image004

clip_image006

clip_image007

And here’s a fiddler trace showing the token response and a base 64 decoded JWT content value with the employeeid claim.

image

Optionally we can have additional permissions defined for our application, so JWT tokens (with employeeid) could also be requested for those resources.

image

Advertisements

Azure AD – Viewing Active Directory Domain Services’ synchronized attributes in Azure AD

leave a comment »

This blog was originally posted to – https://devonblog.com/security/azure-ad/ 

Not every field or property in Azure AD that is synchronized from on premises AD DS (Active Directory Domain Services) is directly visible in the Azure Portal. So how do we establish that the field (employeeid) we desire to synchronize from AD DS to Azure AD is actually present in Azure AD?

We present two ways below to find out whether the employee id attribute from on premises AD DS is synchronized with Azure AD. The below examples show how to view employee id in Azure AD, however the same technique could be used for any other customer field in AD DS or an extension attribute in AD DS that is synchronized with Azure AD.

Azure AD Connect Synchronization Service Manager UI

Open “Azure AD Connect’s Synchronization Rules Editor”, and the outbound rule that is responsible for synchronizing employeeid or any other attribute from the on premise AD DS (Active Directory Domain Services) to Azure AD.

Look at the Transformation section of the Outbound rule that is responsible for synchronizing on premises AD DS data to Azure AD. This step however only shows the attributes of AD DS and against what attributes they are ‘supposed to be synchronized’ in Azure AD.

image

However, when looked at the “Azure AD Connect Synchronization Service Manager UI”, we could actually see the fields (employeeid) and their values that were synchronized with Azure AD from on premise AD DS.

image

Using Microsoft’s Graph API Explorer

Navigate to https://developer.microsoft.com/en-us/graph/graph-explorer and sign in with the organization’s Azure Global Admin account to view the actual synchronized data.

On a slighter note, if including an employee id (or any other information from Azure AD) in the JWT token appears as many steps, then we could also call the Graph API (https://graph.microsoft.com/beta/users/MiriamG@M365x214355.onmicrosoft.com) with an email address and read the employee id as a JSON response. But that is just a workaround, what we actually want is to have employee id as one of the claims in the JWT token itself, so we do not need to query somebody else again to obtain the employee id.

image

Or if the on premised AD DS values are synchronized as extension attributes, then they would have a new name in the Azure AD (with a guid added to their name) as shown in the picture below.

image

Written by gmaran23

October 30, 2018 at 8:52 pm

JWT – Quick reference for parameters in JWT claims

leave a comment »

This blog also appears at https://devonblog.com/author/inmaran/

The last blog explored the JWT header and some of the JSON Web Signature (JWS) parameters. This blog focusses on explaining the claims parameters in the JWT payload.

The oversimplified JWT definition:

JWT has three components.

[MetaInformation].[Claims].[Signature]

Sample JWT in the image below:

clip_image002

1. Base64 – The meta data (or header or manifest) that includes how the token is structured, signed, and so on.

2. Base64 – Claims is what provides the actual meaning of the token.

3. Base64 – Signature intends to provide authenticity and integrity.

https://tools.ietf.org/html/rfc7519#section-10.1.2 describes the registered claims for JWT. An identify provider has the flexibility to add claims that are specific for the intended situations.

Exploring JWT payload:

Let’s look at the JWT payload (aka the data aka the claims)

clip_image004

RFC Reference – registered claims are explained at https://tools.ietf.org/html/rfc7519#section-4.1 (JSON Web Token)

Claims can be ‘registered claims’ or ‘custom defined claims’. Registered claims are just a handful, there is only seven of them however in practice this is the section that has user roles, scopes, and also the most important because it contains the actual content of the JWT.

In the above image which represents a JWT token from Azure AD:

aud:

aud implies the intended audience for the token. This is generally the application or the client or the service that the token is intended for. From a security point of view, the audience claims need to be validated to ensure that the token is indeed issued for the particular application and not for some other application. The aud value is typically an application uri.

iss:

iss is the token issuer, that is the secure token service. In delegated authentication scenarios such an OAuth, the protected resource trusts the identify server that issues tokens. So it is imperative for the resource server to verify that the issued token comes from the issuer that the resource / client trusts. The iss value is typically an uri of the issuer.

iat:

iat is the issued at. Typically the EPOCH time at which the token was issued

nbf:

nbf is the not before. Typically the EPOCH time before which the token should not be accepted for processing an authorization for a resource.

exp:

exp is the expiration time (EPOCH time) after which the token should not be accepted for processing an authorization for a resource

aio:

? there seems to be no available from Microsoft on what aio is ? http://lmgtfy.com/?q=azure+ad+claim+aio

appid:

appid is the id of the application as registered in the Azure App registration. In OAuth terms this is the client_id.

appidacr:

appidacr is the Application Authentication Context Class Reference. appidacr indicates how the client was authenticated. For a public client, the value is 0. If client ID and client secret are used, the value is 1. If a client certificate was used for authentication, the value is 2.  Description borrowed directly from – https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

idp:

idp is the identify provider. Typically same as the value present in the iss claim. The idp value and iss value will be different if the user account is in a different tenant than the issuer. It is worth noting that in Azure AD, the token infrastructure (sts) is shared across multiple tenants.

oid:

oid is the object id that identified the object id as defined in the Azure app registration or the object id of the user in Azure AD

sub:

sub is the subject. Normally the id of the user in the case of ‘authentication code grant’ ‘resource owner password grant’ and ‘implicit grant’ OAUTH flows.

tid:

tid is the tenant identifier of the Azure AD that issued the token. It is worth noting that in Azure AD, the token infrastructure (sts) is shared across multiple tenants.

uti:

? there seems to be no available from Microsoft on what uti is ?

ver:

ver is the JWT token version which at the time of writing is 1.0

Credits and References:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

https://tools.ietf.org/html/rfc7519

https://redthunder.blog/2017/06/08/jwts-jwks-kids-x5ts-oh-my/

https://tools.ietf.org/html/rfc7518

https://tools.ietf.org/html/rfc7515

https://tools.ietf.org/html/rfc7516

Written by gmaran23

October 30, 2018 at 8:48 pm

Posted in jwt, security, token

Tagged with , ,

JWT – Quick reference for the header and JWS parameters

leave a comment »

This blog was originally posted to – https://devonblog.com/security/quick-reference-for-the-header-and-jws-parameters/ 

This blog aims at providing quick reference over the JWT claims and meta information because they are often presented short in three letters to keep them compact. To follow the blog intermediate security knowledge is required.

The oversimplified JWT definition:

JWT has three components.

[MetaInformation].[Claims].[Signature]

Sample JWT in the image below:

clip_image002

1. Base64 – The meta data (or header or manifest) that includes how the token is structured, signed, and so on.

2. Base64 – Claims is what provides the actual meaning of the token.

3. Base64 – Signature intends to provide authenticity and integrity.

https://tools.ietf.org/html/rfc7519#section-10.1.2 describes the registered claims for JWT. An identify provider has the flexibility to add claims that are specific for the intended situations.

Exploring JWT header:

Let’s look at the following JWT sample (base64 decoded) that has the below header information. We will explore the data section subsequently.

clip_image004

RFC reference – https://tools.ietf.org/html/rfc7515#section-4.1 (JSON Web Signature)

typ:

In the above example typ indicates the token type that is JWT

alg:

alg indicates the algorithm type of algorithm used to sign the JWT token. Most commonly used values are RS256, HS256 which stand for RSA-SHA256 (asymmetric) and HMAC-SHA256 (symmetric) respectively.

RS256 alg belongs to the RSA kty (read the kty section below)

x5t:

x5t is the X509 certificate’s thumbprint. That is the certificate whose private key was used to sign the JWT

kid:

kid id the key id indicating which key was used to sign the JWT token. This field is particularly useful when the public key discovery endpoint supports many keys and we need to know which key was used to sign.

In order to verify the signature of the JWT token, the verifier needs to know the public key of the public /private key pair used to sign the JTW token. Most identify providers expose this information via discovery mechanisms such as the one below from Microsoft azure.

clip_image006

In the above example

kty:

If the key type that is the algorithm family used to sign the JWT. RSA, EC are some allowed kty. RS256, RS512 are some algorithms (alg) that belong to the RSA algorithm family (kty)

use:

whether the algorithm is used for enc encryption or sig signing

x5t and kid:

explained above

n:

public key component of the RSA – https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Operation

e:

public key component of the RSA – https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Operation

[Note: If the algorithm kty is EC (elliptic Curve) then the public components are x and y]

x5c:

the x509 certificate chain

The next blog will provide reference information for a sample JWT token from Azure AD.

Credits and References:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens

https://tools.ietf.org/html/rfc7519

https://redthunder.blog/2017/06/08/jwts-jwks-kids-x5ts-oh-my/

https://tools.ietf.org/html/rfc7518

https://tools.ietf.org/html/rfc7515

Written by gmaran23

October 30, 2018 at 8:42 pm

Posted in authorization, encryption, jwt, security, token

Tagged with , , ,

DevSecOps: Integrating OWASP ZAP with GitLab, Calliope.pro functional tests and Slack notifications for reporting

leave a comment »

This blog was originally posted to – https://devonblog.com/security/devsecops-integrating-owasp-zap-with-gitlab-calliope-pro-functional-tests-and-slack-notifications-for-reporting/

We were working with this particular software development team that was working with Mobile Applications, lots of APIs with a cross functional mix of API developers, Android and iPhone developers, QA personnel, architects, UI and UX folks and so on. We base our security consulting using the DevOn’s Continuous Software Security Maturity Model, and three months in to the engagement after some trainings, and initial security assessments it was time to plug in basic security scan as a part of the automation strategy.

Let’s get right to it. The development team that was working with GitLab for version control and Integration needs, with Calliope.pro as their test automation, and of course Slack for chatting (read as collaborating).

Here’s what we wanted to do:

1. Start OWASP ZAP

2. Use the matured API automated test suite that the team has developed via Calliope.pro

3. Let the automated tests proxy their traffic through OWASP ZAP

4. Wait for the functional automated tests to complete

5. Start active scan with OWASP ZAP (with the API-keys and session tokes that were proxied through OWASP ZAP)

6. Send the scan report to Slack

Well, there is many ways to do this, below is the way we chose to get up and running fast with minimal cost of setting and configuring all the nuts and bolts that work together.

Step 1:

Create a test job as “api-tests-proxy” that would run when triggered from Calliope.pro. This test job starts OWASP ZAP to listen on port 8090, then starts the functional automation suite whose traffic is proxied through 8090 to that OWASP ZAP could read the traffic, starts the active scan module of OWASP ZAP using the ZapScan.py file, then uploads the report to Slack

clip_image001

Step 2:

Write the ZapScan.py script to start the OWASP ZAP active scan, extract reports and publish message to Slack

clip_image002

Step 3:

Create and run the new test profile in Calliope.pro

clip_image003

That’s it. Now according to the schedule set in the test runner calliope.pro, the tests will run and reports will be published to the slack channel as intended

clip_image004

The above OWASP ZAP scan is not complete security scanning, nor is it fool proof security testing in any way. The described steps is just a small stepping stone in the entire DevSecOps transformation. The people that receive these reports need to know what’s a High, Medium, Low, or need to have the resources (for example access to a security professional or someone with the security knowledge) to decipher these reports and understand them.

Client Side Storage Security and Sensitive Information

leave a comment »

Storing ‘Sensitive Information’ on client side is a very risky idea. The definition of ‘Sensitive Information’ differs from one application / business / context to another.

HTML5 localStorage
HTML5 sessionStorage
Cookies
Ideal for Storing Sensitive Information No No No
Ideal for Storing Sensitive Information with Encryption Client Side Encryption could be highly complex to implemet, and is not safe enough, compared to server side encryption.

Read more at “Encryption Options” section below.

Client Side Encryption could be highly complex to implemet, and is not safe enough, compared to server side encryption.

Read more at “Encryption Options” section below.

Client Side Encryption could be highly complex to implemet, and is not safe enough, compared to server side encryption.

Read more at “Encryption Options” section below.

 Persistence Till the item is explicitly cleared with localStorage.removeItemAPI  Till the browser/tab closure Based on a defined DateTime that is done via the Set-Cookieexpires response header
 Expiration No predefined expiration time. The data has to be explicitly cleared with localStorage.removeItemAPI

Also when the browser history is cleared (Ctrl + Shift + Delete)

 During the browser/tab closure

Also when the browser history is cleared (Ctrl + Shift + Delete)

During the browser/tab closure for session cookies (cookies that do not have the expires attribute set via the Set-Cookie response header)

Also when the browser history is cleared (Ctrl + Shift + Delete)

 Ideal for storing session tokens (session identifiers, OAUTH tokens, JWTs) No (because it can be compromised via a XSS attack) No (because it can be compromised via a XSS attack) Yes – provided the following cookie flags are set [httpOnlysecuresamesite=lax or samesite=strict]
Sent with every web request for a matching domain? No No Yes

 

Encryption Options:

Encryption requires a key to encrypt and decrypt sensitive information. In case of symmetric encryption algorithm like AES, there is only one key involved in encryption and decryption. In case of asymmetric encryption algorithm like RSA, there is a private key and public key involved for encryption and decryption.

Anybody with the encryption key can easily decrypt the sensitive information to plain text. Hence the key needs to be protected. The ideal place to save the key is on the server side that is behind a firewall to the internet.

In case of encrypting and decrypting an information on the client side, then the encryption key needs to the transferred to the client and typically a javascript module / library performs encryption and decryption of sensitive information. Because the key is transmitted to the client, an intermediate to advanced computer user can use the key to decrypt the sensitive information, thus breaking the logics of encryption and key storage.

There are advanced ways to make this encryption key to be dynamic for every user session, combining a static encryption key with a nonce (random number to be used only once), however the effort involved in implementing such an approach needs to be traded off against moving the encryption logic to the server side. Optional read about the perils of javascript cryptography – here.

Written by gmaran23

February 13, 2018 at 10:23 pm

First Software Security Netherlands Meet Up – Delft – 18 May 2017

leave a comment »

Written by gmaran23

February 12, 2018 at 8:21 pm

N Different Strategies to Automate OWASP ZAP – OWASP APPSec BUCHAREST – Oct 13 2017

leave a comment »

https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2017#tab=Conference_0101_talks

In this talk we will explore the many different ways of automating security testing with the OWASP Zed Attack Proxy and how it ties to an overall Software Security Initiative. Over the years, ZAP has made many advancements to its powerful APIs and introduced scripts to make security automation consumable for mortals. This talk is structured to demonstrate how ZAP’s API, and scripts could be integrated with Automated Testing frameworks beyond selenium, Continuous Integration and Continuous Delivery Pipelines beyond Jenkins, scanning authenticated parts of the application, options to manage the discovered vulnerabilities and so on with real world case studies and implementation challenges.
This is a demonstration oriented talk that explains OWASP ZAP automation strategies for Security Testing by example.

 

 

N Different Strategies to Automate OWASP ZAP – Cybersecurity WithTheBest – Oct 15 2017

leave a comment »

http://cybersecurity.withthebest.com

In this talk we will explore the many different ways of automating security testing with the OWASP Zed Attack Proxy and how it ties to an overall Software Security Initiative. Over the years, ZAP has made many advancements to its powerful APIs and introduced scripts to make security automation consumable for mortals. This talk is structured to demonstrate how ZAP’s API, and scripts could be integrated with Automated Testing frameworks beyond selenium, Continuous Integration and Continuous Delivery Pipelines beyond Jenkins, scanning authenticated parts of the application, options to manage the discovered vulnerabilities and so on with real world case studies and implementation challenges.

 

 

 

Sitecore security hardening 8.2 Downloadable checklist

leave a comment »

Download

One of the developers we were working with Roel (https://in.linkedin.com/in/roelsnetselaar) came up with this checklist for hardening a Sitecore 8.2 installation. Of course you could start hardening a site core installation starting here – https://doc.sitecore.net/sitecore_experience_platform/82/setting_up_and_maintaining/security_hardening.

However almost all deployment scenarios require some sort of checklist to ensure sequential execution of steps to be complete before or during deployment. So, Rather than going through the Site Core hardening documentation and making a checklist of things to be done, download this Sitecore security hardening 8.2 checklist and get started – Sitecore 8.2 security hardening – checklist

 

Preview:

Written by gmaran23

February 12, 2018 at 5:22 pm

Posted in security

Tagged with , ,