http://marcusvannini2012.blogspot.com/
http://www.marcusmoon2022.org/designcontest.htm
Shoot for the moon and if you miss you'll land among the stars...
http://marcusvannini2012.blogspot.com/
http://www.marcusmoon2022.org/designcontest.htm
Shoot for the moon and if you miss you'll land among the stars...
http://marcusvannini2012.blogspot.com/
http://www.marcusmoon2022.org/designcontest.htm
Shoot for the moon and if you miss you'll land among the stars...
http://marcusvannini2012.blogspot.com/
http://www.marcusmoon2022.org/designcontest.htm
Shoot for the moon and if you miss you'll land among the stars...
This technical paper describes the IBM Storwize V7000 Unified system integration with Symantec AntiVirus for NAS, and guidelines for using the IBM Storwize V7000 Unified system with Symantec AntiVirus for NAS to protect the overall system and prevent security threats caused by malware. To know more about the IBM Storwize V7000, visit http://ibm.co/TaLb6Q.
Faster and more efficient Flex System management with Lenovo XClarity Adminis...Principled Technologies
For your administrators, the faster and easier it is to complete repetitive yet complex management tasks, the better. We found that using Lenovo XClarity Administrator took 75 percent less time and 72 percent fewer steps to complete four resource-management use cases on the Flex System, compared to using Cisco UCS Manager on a UCS solution. With better ease of use than UCS Manager and the opportunity to save time and reduce errors, XClarity Administrator and Flex System can be a simpler and more effective combination for your datacenter.
Integration Analysis and guide: Lenovo ThinkServer TS430 in a Dell EnvironmentPrincipled Technologies
Integrating the Lenovo ThinkServer TS430 into an existing Dell environment is not only possible – it’s easy. The Lenovo server fits right into the Dell environment, and you or your IT administrator can access key management features and alerting capabilities. Setting up and configuring your Lenovo ThinkServer TS430 for operation in a Dell-managed environment is a simple, straightforward process that allows you to bring the benefits of the Lenovo ThinkServer TS430 into your existing environment.
2008 08-12 SELinux: A Key Component in Secure InfrastructuresShawn Wells
Presented at SHARE Conference, "SELinux: A Key Component in Secure Infrastructures"
Covers "what is SELinux?," Type Enforcement, SELinux Usage, and example scenarios.
Bridging the Semantic Gap in Virtualized EnvironmentAndy Lee
In virtualization, it is difficult to interpreting the low level state of a VM into high level semantic state of guest OS.
This will be a obstacle for system administrator to real-time observe, inspect and detect the runtime execution of a VM.
Faster and more efficient system management with Lenovo XClarity AdministratorPrincipled Technologies
We found that automating provisioning tasks with Lenovo XClarity Administrator saved over 58 minutes total across three use cases—a total time savings of 95 percent—and required 75 percent fewer total steps. Specifically, configuring a compute node required 80 percent less time and 19 fewer steps; deploying VMware ESXi to a bare-metal node required 94 percent less time and 23 fewer steps; and updating firmware required 98 percent less time and 33 fewer steps using XClarity Administrator compared to manually executing these tasks. Automating processes for your Lenovo Flex System chassis and nodes can mean less required time and labor from your administrators. This can translate to simplifying their day and allowing them to devote more time to other projects and sooner than anticipated.
3.6.2015 järjestimme Konesali -ja tietoturvatapahtuma Best of Brainsharen asiakkaille ja kumppaneillemme.
Files Matter, edelleen. Novell Filr -ratkaisulla tehostat työntekoa, tiedonkulkua ja dokumenttien kommentointia. Jaat tärkeät asiakirjat ja dokumentit haluamillesi henkilöille ja annat heille oikeuden jakaa tiedostoja sinulle.
Filr on yritystason ratkaisu, joka yhdistää käyttäjät suoraan nykyisiin tiedostoihin ja mahdollistaa niiden jakamisen yrityksen sisäisille sekä ulkoisille käyttäjille. Se on palvelinarkkitehtuurin välttämätön laajennus, kun haluat tarjota nykyaikaisen, tietoturvallisen ja tehokkaan tiedostojen käytön kaikilla nykyaikaisilla päätelaitteilla.
Operations Management Suite, the Penguins and the othersChristian Heitkamp
With the addition of the OMS Linux agent, OMS took a great leap forward by providing more functionalities than ever before. In this session, we will take a closer look at the Linux Agent and providers like the unified log data collector + others. If you have heard of Zabbix, Nagios, Icinga, you want to attend this session. We will do a live hands-on demo and integrate other Operations Management systems with OMS, elevating OMS to a real Operations Bridge with full analytics possibilities across IT management domains. To close off the session, we will spend some time on OMS and IOT too.
Christian Heitkamp (Germany)
Level 300
This technical paper describes the IBM Storwize V7000 Unified system integration with Symantec AntiVirus for NAS, and guidelines for using the IBM Storwize V7000 Unified system with Symantec AntiVirus for NAS to protect the overall system and prevent security threats caused by malware. To know more about the IBM Storwize V7000, visit http://ibm.co/TaLb6Q.
Faster and more efficient Flex System management with Lenovo XClarity Adminis...Principled Technologies
For your administrators, the faster and easier it is to complete repetitive yet complex management tasks, the better. We found that using Lenovo XClarity Administrator took 75 percent less time and 72 percent fewer steps to complete four resource-management use cases on the Flex System, compared to using Cisco UCS Manager on a UCS solution. With better ease of use than UCS Manager and the opportunity to save time and reduce errors, XClarity Administrator and Flex System can be a simpler and more effective combination for your datacenter.
Integration Analysis and guide: Lenovo ThinkServer TS430 in a Dell EnvironmentPrincipled Technologies
Integrating the Lenovo ThinkServer TS430 into an existing Dell environment is not only possible – it’s easy. The Lenovo server fits right into the Dell environment, and you or your IT administrator can access key management features and alerting capabilities. Setting up and configuring your Lenovo ThinkServer TS430 for operation in a Dell-managed environment is a simple, straightforward process that allows you to bring the benefits of the Lenovo ThinkServer TS430 into your existing environment.
2008 08-12 SELinux: A Key Component in Secure InfrastructuresShawn Wells
Presented at SHARE Conference, "SELinux: A Key Component in Secure Infrastructures"
Covers "what is SELinux?," Type Enforcement, SELinux Usage, and example scenarios.
Bridging the Semantic Gap in Virtualized EnvironmentAndy Lee
In virtualization, it is difficult to interpreting the low level state of a VM into high level semantic state of guest OS.
This will be a obstacle for system administrator to real-time observe, inspect and detect the runtime execution of a VM.
Faster and more efficient system management with Lenovo XClarity AdministratorPrincipled Technologies
We found that automating provisioning tasks with Lenovo XClarity Administrator saved over 58 minutes total across three use cases—a total time savings of 95 percent—and required 75 percent fewer total steps. Specifically, configuring a compute node required 80 percent less time and 19 fewer steps; deploying VMware ESXi to a bare-metal node required 94 percent less time and 23 fewer steps; and updating firmware required 98 percent less time and 33 fewer steps using XClarity Administrator compared to manually executing these tasks. Automating processes for your Lenovo Flex System chassis and nodes can mean less required time and labor from your administrators. This can translate to simplifying their day and allowing them to devote more time to other projects and sooner than anticipated.
3.6.2015 järjestimme Konesali -ja tietoturvatapahtuma Best of Brainsharen asiakkaille ja kumppaneillemme.
Files Matter, edelleen. Novell Filr -ratkaisulla tehostat työntekoa, tiedonkulkua ja dokumenttien kommentointia. Jaat tärkeät asiakirjat ja dokumentit haluamillesi henkilöille ja annat heille oikeuden jakaa tiedostoja sinulle.
Filr on yritystason ratkaisu, joka yhdistää käyttäjät suoraan nykyisiin tiedostoihin ja mahdollistaa niiden jakamisen yrityksen sisäisille sekä ulkoisille käyttäjille. Se on palvelinarkkitehtuurin välttämätön laajennus, kun haluat tarjota nykyaikaisen, tietoturvallisen ja tehokkaan tiedostojen käytön kaikilla nykyaikaisilla päätelaitteilla.
Operations Management Suite, the Penguins and the othersChristian Heitkamp
With the addition of the OMS Linux agent, OMS took a great leap forward by providing more functionalities than ever before. In this session, we will take a closer look at the Linux Agent and providers like the unified log data collector + others. If you have heard of Zabbix, Nagios, Icinga, you want to attend this session. We will do a live hands-on demo and integrate other Operations Management systems with OMS, elevating OMS to a real Operations Bridge with full analytics possibilities across IT management domains. To close off the session, we will spend some time on OMS and IOT too.
Christian Heitkamp (Germany)
Level 300
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
2. Differences between the products
Although IBM Encryption Key Manager and Tivoli Key Lifecycle Manager both serve
encryption keys to tape drives, the ways in which they do so differ. For example, Encryption
Key Manager accesses an existing keystore that is managed independently from the key
manager. Tivoli Key Lifecycle Manager manages the keystore internally. Figure 1 depicts an
architectural comparison diagram.
Figure 1 Product comparison
2 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
3. Encryption Key Manager operations
Encryption Key Manager is a Java™ process that accesses a keystore through Java
Cryptography Extension (JCE) interfaces. Encryption Key Manager keeps track of its drives,
metadata, and logs in UNIX System Services files. The keystore is managed through
processes that are external to Encryption Key Manager.
Encryption Key Manager uses a configuration or properties file to maintain attributes about
the installation. The systems programmer usually manages this properties file. Specific
attributes, such as default key labels, are maintained in this property file.
During migration, the configuration, keystore file, as well as drive and metadata information,
are moved into the Tivoli Key Lifecycle Manager environment.
Typically, on z/OS, Encryption Key Manager runs as a started task in a JzOS environment.
Commands are issued to Encryption Key Manager through the z/OS MODIFY operator
command.
Figure 2 shows the architectural components of an Encryption Key Manager infrastructure.
Figure 2 Encryption Key Manager components
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 3
4. Tivoli Key Lifecycle Manager operations
Tivoli Key Lifecycle Manager is a System Services Runtime Environment (SSRE) application
Java process that accesses a keystore through Java JCE interfaces. Tivoli Key Lifecycle
Manager keeps track of its drives and metadata using IBM DB2® tables, and logs in UNIX
System Services files. The keystore is managed internally through the Tivoli Key Lifecycle
Manager interfaces.
Tivoli Key Lifecycle Manager runs under the management of SSRE, which is a WebSphere®
Application Server on z/OS for especially entitled applications; Tivoli Key Lifecycle Manager is
one of these entitled applications.
Tivoli Key Lifecycle Manager manages its configuration files internally. Administrators of Tivoli
Key Lifecycle Manager access changeable properties through the Integrated Solutions
Console (ISC) Web-based interface. The ISC creates and manages the keys.
Figure 3 shows the architectural components of a Tivoli Key Lifecycle Manager infrastructure.
Figure 3 Tivoli Key Lifecycle Manager components
4 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
5. Planning the migration
Moving from an Encryption Key Manager environment to the Tivoli Key Lifecycle Manager
environment enables you to have more control over your key management infrastructure.
Encryption Key Manager only reads keys from a preexisting and separately managed
keystore; however, Tivoli Key Lifecycle Manager creates and manages the keystore, as well
as the keys that it contains. When Encryption Key Manager is migrated to Tivoli Key Lifecycle
Manager, the keys in the existing keystore, drive table information, and metadata are brought
into the new Tivoli Key Lifecycle Manager environment. Tivoli Key Lifecycle Manager uses
DB2, as well as system files, to manage metadata.
Important considerations
Before you begin, consider the following issues. Ensure that your organization allows a time
interval for a temporary halt to key serving activity. While the migration runs, no key serving
activity can occur. A window of testing in a test environment is also required to ensure that the
new Tivoli Key Lifecycle Manager has the expected keys and other configuration attributes
that you intended to migrate.
Back up the Encryption Key Manager server that has the configuration data that you intend to
migrate. Migrated data includes these types of information:
A configuration properties file.
Keys and certificates that are referenced by the configuration properties file.
Drive tables.
An optional metadata file to which the configuration properties file points.
An optional key groups file.
Migrate only one Encryption Key Manager server to one Tivoli Key Lifecycle Manager
server. To migrate a second Encryption Key Manager server, use a second Tivoli Key
Lifecycle Manager server.
Both the Encryption Key Manager server and the Tivoli Key Lifecycle Manager server that
receives the migrated data must be on the same z/OS system, which must be at Version 1,
Release 9 or later.
After migration, the Tivoli Key Lifecycle Manager server uses the keystore, TCP port, and
Secure Sockets Layer (SSL) port that the Encryption Key Manager server previously used.
Before you migrate, refresh and stop the Encryption Key Manager server to ensure that
there is no data loss. Encryption Key Manager cannot be active when you perform the
actual migration.
Migration restrictions
Encryption Key Manager supports a separate set of keystores and manages keys differently
than Tivoli Key Lifecycle Manager. There are certain restrictions on what information will be
migrated:
The migration of Administrator SSL keystores and truststores is not supported. The Tivoli
Key Lifecycle Manager server does not support the Administrator synchronization
capability.
The migration of PKCS11Impl keystores and truststores is not supported. The Tivoli Key
Lifecycle Manager server does not support PKCS11Impl keystores. Because this
migration is on z/OS, no PKCS11Impl keystore exists. So, this restriction does not apply.
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 5
6. Tivoli Key Lifecycle Manager does not support the use of a key in multiple groups, unlike
Encryption Key Manager, which allows the use of a key in multiple groups. Keygroups are
sets of symmetrical keys that are used for LTO-4 drive-based encryption. This restriction
only becomes an issue if the keystore that is being migrated is of the JCEKS type (a flat
UNIX file).
When you migrate key data in the KeyGroup.xml file from Encryption Key Manager to Tivoli
Key Lifecycle Manager, each key is attached to one group. A key that was previously in
multiple groups in Encryption Key Manager is created in only one group in Tivoli Key
Lifecycle Manager. This restriction only becomes an issue if the keystore being migrated is
of the type JCEKS.
Migrating data objects and properties
The following data objects are migrated.
Keystores
Encryption Key Manager has several types of keystores, each with a separate purpose.
These keystores are listed in the Encryption Key Manager properties file:
config.keystore.file Used to hold encryption keys. Migrated to Tivoli
Key Lifecycle Manager.
TransportListener.ssl.keystore.name Used for Encryption Key Manager server
authentication. Migrated to Tivoli Key Lifecycle
Manager.
TransportListener.ssl.truststore.name Used for Encryption Key Manager client
authentication. Not migrated to Tivoli Key Lifecycle
Manager.
Admin.ssl.keystore.name Used when Encryption Key Manager is a target
server for sync operations. Not migrated to Tivoli
Key Lifecycle Manager.
Admin.ssl.truststore.name Used when Encryption Key Manager is a client for
sync operations. Not migrated to Tivoli Key
Lifecycle Manager.
Note that Encryption Key Manager uses the term truststore to denote keystores from
certificates that are used by clients. Because the Tivoli Key Lifecycle Manager clients
authenticate to the WebSphere Application Server environment, either through the ISC or the
CLI using wsadmin, no client side keystore or truststore is necessary.
Tivoli Key Lifecycle Manager supports only one keystore, which is identified by the
config.keystore.name property in the TKLMgrConfig.properties file. This keystore is
equivalent to the Encryption Key Manager Config keystore (config.keystore.file).
During migration, the two Encryption Key Manager keystores, config.keystore.file and
TransportListener.ssl.keystore.name, are merged into the single Tivoli Key Lifecycle Manager
keystore. The resulting keystore is created with a default name of Tivoli Key Lifecycle
Manager Keystore. That is, this entry is in the TKLMgrConfig.properties file:
config.keystore.name = Tivoli Key Lifecycle Manager Keystore
6 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
7. All certificates from the Encryption Key Manager config.keystore.file keystore are added to
the Tivoli Key Lifecycle Manager keystore. All the certificates from the
TransportListener.ssl.truststore.name truststore are added to the Tivoli Key Lifecycle
Manager keystore, and one of the certificates is set as an SSL certificate. The
config.keystore.ssl.certalias property is updated with the alias of this certificate. This
certificate is used to secure communications between the ISC GUI and the Tivoli Key
Lifecycle Manager server.
Other Encryption Key Manager keystores are not used.
Devices
All the device information is read from the drive table pointed at by the config.drivetable.file.url
property, and it is entered in a Tivoli Key Lifecycle Manager database. If the drive has the
symalias property defined, the drive type is set to LTO. If the drive has aliases defined, the
drive type is set to 3592. If the drive does not have any of these properties defined and the
type cannot be determined during migration, the type is set to UNKNOWN.
Keygroups
The keygroup.xml file, to which the config.keygroup.xml.file property points, is parsed, and
the keygroup information is stored in a Tivoli Key Lifecycle Manager database. All the group
members and group relationships are also migrated. The group member and group
relationship migration only applies to Encryption Key Manager Version 2.1.
Metadata
All the metadata information, to which the audit.metadata.file.name property points, is
migrated to a Tivoli Key Lifecycle Manager database. This metadata migration only applies to
Encryption Key Manager versions 2.0 and 2.1.
Properties
The following properties are migrated from the Encryption Key Manager configuration file to
the TKLMgrConfig.properties file:
audit.eventQueue.max
audit.handler.file.size
audit.event.outcome
audit.event.types
config.keystore.name (set to Tivoli Key Lifecycle Manager Keystore)
cert.valiDATE
drive.acceptUnknownDrives
drive.default.alias1
drive.default.alias2
fips
symmetricKeySet (set to DefaultMigrationGroup if it was not a symmetricKeySet,
otherwise, set to the groupName)
TransportListener.ssl.ciphersuites
TransportListener.ssl.clientauthentication
TransportListener.ssl.port
TransportListener.ssl.protocols
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 7
8. TransportListener.ssl.timeout
TransportListener.tcp.port
TransportListener.tcp.timeout
useSKIDefaultLabels
zOSCompatibility
When to migrate
It is important that you understand when to migrate Encryption Key Manager to Tivoli Key
Lifecycle Manager. Because Tivoli Key Lifecycle Manager manages the keys’ life cycles, it
needs to track more than just the existence of the keys.
Tivoli Key Lifecycle Manager manages this information in several DB2 tablespaces. Although
Encryption Key Manager can continue to serve keys after its data is migrated to Tivoli Key
Lifecycle Manager, it is important to know that you can only migrate Encryption Key Manager
one time. Any keys that are added to the Encryption Key Manager keystore after migration will
not be recognized by Tivoli Key Lifecycle Manager.
Tivoli Key Lifecycle Manager will take control of the Encryption Key Manager keystore. For
example, if the keystore is a JCERACFKS RACF® keyring, that same keyring and user ID will
be used by Tivoli Key Lifecycle Manager. Data is not moved to a new keyring. Also, Tivoli Key
Lifecycle Manager will take control of the Encryption Key Manager keystore in the same way if
the keystore is a JCEKS UNIX file. Tivoli Key Lifecycle Manager will read the keystore and
create metadata in DB2 for its contents.
You can only migrate Encryption Key Manager to Tivoli Key Lifecycle Manager at one of these
times:
During the Tivoli Key Lifecycle Manager installation process
After the Tivoli Key Lifecycle Manager installation completes, but before the creation of the
Tivoli Key Lifecycle Manager master keystore
Master keystore: After Tivoli Key Lifecycle Manager has created a master keystore, you
cannot migrate Encryption Key Manager to Tivoli Key Lifecycle Manager.
8 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
9. Preparing for the migration
You must complete the following tasks, if applicable, before starting the migration from
Encryption Key Manager to Tivoli Key Lifecycle Manager on z/OS:
1. Set the required permissions for the Encryption Key Manager files. This discussion uses
the Encryption Key Manager property values (Table 1) to denote the files to which
SSRECFG requires READ access. Refer to the Encryption Key Manager properties file for
installation-specific filenames.
Table 1 Required file permissions for migration
Property Use
config.drivetable.file.url Drivetable: The tracking of drives to keys used
by Encryption Key Manager.
config.keygroup.xml.file Keygroups file: Information about what
symmetric keys are grouped together. Used by
LTO-4 drives.
audit.metadata.file.name Audit metadata file: Encryption Key Manager
Version 2.0 and higher only.
config.keystore.file For keystores of type JCEKS, JCE4758KS, or
JCECCAKS, give READ and WRITE
Depending on the value of config.keystore.type, permissions to the keystore file and READ and
this property might be a Resource Access WRITE permissions to the full directory path in
Control Facility (RACF) keyring or a flat file. which the keystore is located.
For a RACF keystore (that is, of type
JCERACFKS, JCE4578RACFKS, or
JCECCARACFKS), give the SSREGRP group
ID permissions to the Encryption Key Manager
keyring, keys, and certificates.
2. Ensure that the following values in the Encryption Key Manager properties file are defined
as absolute paths:
– audit.metadata.file.name
– config.drivetable.file.url
– config.keygroup.xml.file
Setting up permissions to RACF keyrings and certificates
You must perform the following preparations for the System Services Runtime Environment
configuration ID, such as SSRECFG, and for the user ID to which the System Services
Runtime Environment-started task is associated, such as SSREADM. These IDs must be
able to create and access keyrings before you select and configure the RACF keyring using
the GUI panels in Tivoli Key Lifecycle Manager.
From the directory where the tklm.jar file was expanded, edit the racfpermissions.rexx exec:
oedit samples/racfpermissions.rexx
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 9
10. You must review the set of variables that follows the prolog in the racfpermissions.rexx script:
groupid This variable is the ID of the group of Tivoli Key Lifecycle Manager users. By
default, the permissions in this sample script are granted at the group level (that
is, SSREGRP). This value can be any RACF ID (either user ID or group ID) that
needs access to the keyring.
Default groupid = SSREGRP
userid This variable is the user ID. It is only used one time in this script. The user ID
must be the SSRE-started task user ID, which defaults to SSREADM.
Default userid = SSREADM
ownerid This variable is the user ID of the owner of the EKM master keystore keyring. A
typical Encryption Key Manager installation might have used user ID
EKMSERV.
Default ownerid = OWNERID
keyring This variable is the name of the Encryption Key Manager keyring to which the
SSRE group is being granted access. A typical Encryption Key Manager
installation might have used a ring name of EKMRing.
Default keyring = KEYRING
You can use a REXX script by running the script directly in OMVS. Or, you can copy the script
into a dataset and run the script in the TSO command line by using the following command:
To execute from the UNIX System Services environment:
– Insure that the correct UNIX permissions are set for accessing the file:
chmod 755 racfpermissions.rexx
– Run the executable (this example shows the executable being run from the samples
directory):
. ./racfpermissions.rexx
To execute from the Time Sharing Option Extensions (TSO)/E environment:
– Copy the executable to a partitioned dataset (for example, HLQ.REXX(sample))
cp racfpermissions.rexx "//''HLQ.REXX(sample)' "
We describe the RACF commands that are issued from the racfpermissions.rexx script in
“Appendix: RACF commands” on page 13.
10 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
11. Running the migration
Perform these steps to migrate Encryption Key Manager on a z/OS system to Tivoli Key
Lifecycle Manager:
1. Ensure that Encryption Key Manager is stopped:
– If running Encryption Key Manager under a started task, stop the Encryption Key
Manager started task (that is, EKMPROC) by issuing the following z/OS operator STOP
command:
STOP EKMPROC
– If running Encryption Key Manager from a UNIX System Services shell, stop the
Encryption Key Manager process with the following tasks:
• Start the CLI client from the UNIX System Services shell:
java com.ibm.keymanager.KMSAdminCmd CLIconfiglfile_name -i
• Before submitting any commands, you must log the CLI client in to the key manager
server with the following command:
#login –ekmuser EKMAdmin –ekmpassword changeME
• Finally, you can issue the stopekm command:
stopekm
Another method is to send a sigterm command to the key manager process, which
allows the server to shut down and end cleanly.
Note: Do not send a sigkill command to the key manager process. The
sigkill command does not shut down the process cleanly. Configuration
options and other data might be lost.
2. Insure that the SSRE user ID has READ WRITE access to the following Encryption Key
Manager resources:
– Drivetable as noted by the config.drivetable.file.url property in the Encryption Key
Manager properties file.
– Keygroups file as noted by the config.keygroup.xml file. Skip this step if the
Encryption Key Manager that is being migrated does not serve LTO devices.
– Audit metadata file as noted by the audit.metadata.file.name property in the Encryption
Key Manager configuration file.
– Give the SSREGRP group ID permissions to read and write to the Encryption Key
Manager keystore.
Locate the keystore and the type of keystore to migrate from Encryption Key Manager.
Examine the config.keystore.file and config.keystore.type properties in the Encryption
Key Manager properties file. Then, take one of these steps based on the keystore type:
• For keystores of type JCEKS, JCE4758KS, or JCECCAKS, give READ and WRITE
permissions to the keystore file and READ and WRITE permissions to the full
directory path in which the keystore is located. The migration process requires the
WRITE permission to back up the keystore before the migration begins.
• For a RACF keystore (that is, of type JCERACFKS, JCE4578RACFKS, or
JCECCARACFKS), give the SSREGRP group ID permissions to the Encryption
Key Manager keyring, keys, and certificates. For an example of how to give these
permissions, see “Appendix: RACF commands” on page 13.
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 11
12. 3. Run the migration manually, after you have successfully installed Tivoli Key Lifecycle
Manager.
Run the migration script by using this shell script from the directory where the tklm.jar file
was expanded:
./bin/migrateEKM.sh
Specify these optional parameters:
-responseFile response_file Specifies the response file that is created during the
createResponseFile.sh step that the Tivoli Key Lifecycle
Manager installation program provides. If you do not
specify this option, the migration process looks for the
default response file name, which is the
POST_SMPE_TKLM_HOME/bin/tklmInstall.response file.
In this example, the value is the
/etc/tklm/bin/tklmInstall.response file.
-wasPassword was_password Specifies the SSRECFG user ID password. If you do not
supply a password, you are prompted for the value in a
secure manner.
-dbPassword db_password Specifies the password of the Tivoli Key Lifecycle
Manager database owner. If you do not supply a
password, you are prompted for the value in a secure
manner.
-v Specifies sending verbose output to the console. The
migration process always sends verbose output to a
migration log.
The output in Example 1 occurs when you run the migrateEKM.sh shell script with no
specified parameters.
Example 1 Migration command sample output
Log file "/etc/tklm/logs/migrateEKM_100808_163341.log"
will be used for this run
No response file passed. Defaulting to
"/etc/tklm/bin/tklmInstall.response"
Enter the fully qualified path name of the EKM configuration file:
/home/suimglb/bin/KeyManagerConfig.properties.JCERACFKS
Accepted input: ["/home/suimglb/bin/KeyManagerConfig.properties.JCERACFKS"]
Stopping SSRE...
SSRE stopped
Running Migration API
Starting SSRE...
SSRE started
TKLM Migration has succeeded
Script completed with exit code: 0(SUCCESS)
Note that SSRE is stopped and restarted during this process.
12 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
13. Summary
By following these instructions, you can upgrade the existing Encryption Key Manager
solution with a new look, new capabilities, and an easier to use interface.
After migrating the Encryption Key Manager environment to Tivoli Key Lifecycle Manager, you
can perform key management for tape and disk devices at a GUI from a Web-based portal.
Key management for Encryption Key Manager was performed at a terminal using
sophisticated and complex commands. Device management was performed at libraries or
from within data management routines.
Tivoli Key Lifecycle Manager allows the user to assign keys to devices from a streamlined
interface. Key management is simplified by providing rollover schedules for default keys and
certificates.
As the need for encryption key management evolves and grows, Tivoli Key Lifecycle Manager
is positioned to take advantage of simplified key life-cycle management capabilities in a
solution that is easy to manage.
Appendix: RACF commands
The racfpermissions.rexx script executes the following commands to use RACF keyrings from
Tivoli Key Lifecycle Manager:
1. Define the RACF profiles:
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADD UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.DELETE UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADDRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CONNECT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENREQ UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ALTER UACC(NONE)
2. Grant the proper authorizations to both user IDs:
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(SSRE_USERID) ACC(UPDATE)
PERMIT IRR.DIGTCERT.ADD CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.DELETE CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.ADDRING CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.CONNECT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.GENREQ CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
PERMIT IRR.DIGTCERT.ALTER CLASS(FACILITY) ID(SSRE_USERID) ACC(CONTROL)
ALTUSER SSRE_USERID CLAUTH(DIGTCERT)
SETROPTS RACLIST(FACILITY)
SETROPTS RACLIST(FACILITY) REFRESH
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 13
14. For more information about RACF keyrings, syntax, and commands, see the z/OS Security
Server RACF Security Administrator Guide, SA22-7683-11, and z/OS Security Server RACF
Command Language Reference, SA22-7687-11.
The team who wrote this IBM Redpaper
This paper was produced by specialists from around the world working at the International
Technical Support Organization, Austin Center.
William C. Johnston, CISSP, is a Master Certified IT Specialist with experience working with
large system installations to deploy encryption key management solutions. He has performed
enterprise system security assessments. A large part of his duties include educating clients
about security-related topics and bringing best practices to client processes. For over a
decade, he was responsible for the design and implementation of the test approach
definitions for security-related elements of the z/OS operating system, including their
interaction with other components, the base OS, and other platforms, such as Linux® and
Windows® XP. In the past, he has performed code development, functional and system-level
testing, and project management duties. William is an adjunct professor at Marist College in
Poughkeepsie, New York.
Axel Buecker is a Certified Consulting Software IT Specialist at the ITSO, Austin Center. He
writes extensively and teaches IBM classes worldwide about areas of software security
architecture and network computing technologies. He holds a degree in Computer Science
from the University of Bremen, Germany. He has 23 years of experience in a variety of areas
related to workstation and systems management, network computing, and e-business
solutions. Before joining the ITSO in March 2000, Axel worked for IBM in Germany as a
Senior IT Specialist in Software Security Architecture.
Thanks to the following people for their contributions to this project:
Jonathan M. Barney, Steven R. Hart, and John Petreshock of IBM, without whose help,
developing this Redpaper would not have been possible.
Now you can become a published author, too!
Here’s an opportunity to spotlight your skills, grow your career, and become a published
author - all at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
14 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
15. Stay connected to IBM Redbooks and Redpapers
Find us on Facebook:
http://www.facebook.com/pages/IBM-Redbooks/178023492563?ref=ts
Follow us on twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager 15
16. 16 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager
18. This document REDP-4646-00 was created or updated on April 12, 2010.
Send us your comments in one of the following ways: ®
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A. Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
DB2® RACF® Tivoli®
DS8000® Redpaper™ WebSphere®
IBM® Redbooks (logo) ® z/OS®
The following terms are trademarks of other companies:
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
18 Tivoli Key Lifecycle Manager for z/OS: Migration Guide for the IBM Encryption Key Manager