Shadow IT Software Development - End User Linux PC Side Mitigation Controls with Mandatory Access Control and Logging

Shadow IT Software Development - End User Linux PC Side Mitigation Controls with Mandatory Access Control and Logging | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Shadow IT Software Development - End User Linux PC Side Mitigation Controls with Mandatory Access Control and Logging Joshua Nathaniel Haupt This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-7811422/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract Shadow Information Technology (IT) encompasses all hardware, software, or other solutions used by employees within the organisational ecosystem that have not received formal approval from the IT department. Shadow IT is a problem in many large organizations that handle sensitive information and infrastructure. [ 1 ] Shadow software development is a subset of shadow IT, where undocumented applications are developed and deployed within enterprise environments. This paper outlines the use of Mandatory Access Control and proper logging of attempted usage of development tools, such as controls that can be implemented on the end-user or client side, to mitigate the risk of shadow application development. Software Engineering cyber security information security software development Figures Figure 1 Risks The risks associated with shadow IT are quite costly, with the global average cost of a data breach in 2024 being $4.88 million. The costs include expensive compliance violations, as well as legal and reputational risks, especially if sensitive data is compromised. [2] Both data breaches and integrity failures typically stem from mishandling data at rest, in transit, or in use. Data breaches can result from improper data handling, such as using sensitive customer information in non-secure testing databases, utilizing unauthorized external databases, employing vulnerable third-party software libraries, and hardcoding sensitive credentials instead of properly vaulting them using a platform like Hashicorp Vault. Data integrity compromise is a significant risk associated with shadow IT, as such solutions often lack robust testing and safeguards, and are frequently of lower quality. For instance, in a distributed Robotics Process Automation (RPA) project, a shared Microsoft Access database held critical workflow data. An accidental mouse movement deleted essential rows, disrupting the entire process mid-execution. Inadequate controls against shadow software development can provide new threat vectors for ransomware and insider attacks, as unauthorized tools may be leveraged by malicious actors. From this diagram, by Zimmermann [3], you can see that how a shadow IT implementation should be handled is based on the correlation between the quality of the implementation and the relevance and criticality of the implementation. If a shadow IT implementation is of low quality, but high relevance and criticality, mitigation efforts often require renovation, or fixing, and if necessary, rebuilding it. On the other hand, if the quality of a shadow IT implementation is very high, it may be safe enough to just register the implementation. Instances of shadow IT implementations that are in between require some coordination, as some renovation or fixes may still be necessary before they can be registered for proper utilization. Motives - IT Side On the IT side, shadow software development often results from developer frustration with the available tools and resources within the enterprise. This can be due to a lack of adequate testing environments or development tools, such as Integrated Development Environments (IDEs) or debugging tools, that are available for use. The frustration with, or even lack of, internal developer platforms is another cause. Obviously, if no internal development platform exists, it can be a chaotic free-for-all. However, even if one does exist, it is often the case that developers may not understand how to properly utilize it, often due to inadequate training. Additionally, they may also be frustrated with a lack of support for using the platform. Motives - Business Side On the business side, there may be a lack of support from IT or other development teams to implement necessary solutions for the business. As a result, business users may experiment with no-code / low-code platforms as well as Robotic Process Automation (RPA). Control Objectives The proposed controls to be discussed for preventing shadow software development must satisfy the following conditions. 1.) They must ensure that only authorized users can access development tools. 2.) Both unauthorized and improper usage of development tools needs to be logged to enable upstream auditing. These controls can be implemented on end clients and on the network. Controls - End User Personal Computers (PCs) Require all network traffic to flow through the enterprise network to prevent the use of unapproved web and cloud services. If an end-user device is used remotely, all of its network traffic should be routed through an enterprise VPN. This control and its implementation are a prerequisite for Only allow approved software to be requested, downloaded, and installed from trusted internal repositories. Restrict user access to development tools. Restrict the ability to request development tools to authorized users only. Restrict the development tools users can request to only those that are necessary for their job function. Through Mandatory Access Control [a], restrict the ability to execute or run development tools based on the user's group memberships. Unauthorized attempts to use development tools should be logged for upstream auditing. On Linux and other Unix-based systems, this can be implemented with proper permission configurations that are owned by the root user, allowing them to be centrally managed. These permissions need to restrict execution permissions to development tools to users of a specifically designated developers group. Further enforcement of proper usage of development tools and logging attempts at improper usage can be handled on Linux systems with centrally managed kernel security modules, such as AppArmor. Security-Enhanced Linux (SELinux) was evaluated in my experiments; however, during my lab experiments, I did not find it to be a practical tool for restricting the use of development tools on development systems used by individual users. Lab Setup For the lab environment in which I tested my hypotheses, I used two separate laptops: one running Fedora 41 Workstation Edition and another running Ubuntu 24.04.3 LTS. End User PC Side Control Implementation - Use Mac to Restrict Access to Development Tools The utilization of MAC to restrict development tools, such as IDEs, consoles, and text editors to write to and execute code in designated development directories is an additional control that should be implemented as it relates to PO.5 - 'Implement and Maintain Secure Environments for Software Development of the SSDF. [6] This is more AppArmor, as both allow for fine-grained policies that can restrict who can access an application and where applications can write to. A drawback is having to maintain security policies for every development tool. Another drawback is that implementation can be challenging for specific groups that have access to it. However, this drawback can be mitigated by assigning developers a secondary account or secondary developer machines. Both of these controls not only relate to PO.5, but also enable streamlined auditability, as all activity involving these secondary accounts or machines can be logged and monitored as development activity. In my lab environment, on both the Fedora and Ubuntu machines, I was able to successfully restrict access to development tools, such as the nano, emacs, editors and the clang, gcc, and g++ compilers by setting the group ownership of binaries of the relevant binaries in /usr/bin/ to the "devs" group, and then removing the execute permissions for non owner or group members. I was also able to implement logging by configuring audit.d to monitor for failed execution, or "execve" system calls for non-system and non-root users. Here are the commands to restrict development application binaries to members of a specific group, in this case, the "devs" group. sudo groupadd devs sudo usermod -aG devs josh sudo chown root:devs /usr/bin/nano sudo chmod 710 /usr/bin/nano sudo chown root:devs /usr/bin/emacs sudo chmod 710 /usr/bin/emacs sudo chown root:devs /usr/bin/clang sudo chmod 710 /usr/bin/clang sudo chown root:devs /usr/bin/gcc sudo chmod 710 /usr/bin/gcc Here are the required rules that need to be added as a rules file under /etc/audit/rules.d/. sudo cat /etc/audit/rules.d/denied.rules -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,execve -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access -a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,execve -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,execve -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access -a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,execve -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access This is what a user outside of the "devs" group will see when they try to run a restricted development tool, which in this case is nano. nondev@josh-ubuntu-laptop:~$ nano bash: /usr/bin/nano: Permission denied This is an audit log that is generated when a user named "nondev" who is outside of the "devs" group tries to run a restricted development tool such as nano. sudo cat /var/log/audit/audit.log type=SYSCALL msg=audit(1759799497.953:1669): arch=c000003e syscall=59 success=no exit=-13 a0=5a8a296a7c00 a1=5a8a296a7ba0 a2=5a8a2968d190 a3=5a8a296a7ba0 items=1 ppid=15098 pid=18160 auid=1000 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts4 ses=3 comm="bash" exe="/usr/bin/bash" subj=unconfined key="access"ARCH=x86_64 SYSCALL=execve AUID="josh" UID="nondev" GID="nondev" EUID="nondev" SUID="nondev" FSUID="nondev" EGID="nondev" SGID="nondev" FSGID="nondev" type=CWD msg=audit(1759799497.953:1669): cwd="/home/nondev" type=PATH msg=audit(1759799497.953:1669): item=0 name="/usr/bin/nano" inode=394303 dev=08:02 mode=0100710 ouid=0 ogid=1002 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="devs" type=PROCTITLE msg=audit(1759799497.953:1669): proctitle="bash" In my lab environment, I successfully tested this using AppArmor on the Ubuntu machine. I configured two separate users, one outside of a devs group and another in the devs group. The user outside of the devs group was restricted from running most development tools, such as editors and compilers. While the user in the devs group was able to use such tools only while working inside the designated dev directory. Here is an example of an AppArmor profile configuration that restricts the nano text editor's write permissions to a "dev" directory that is in their home directory by specifically whitelisting the"home/*/dev/" directory and all of its sub directories for the file "owner" which in this case will be the user "josh".owner /home/*/dev/ rw," and " owner /home/*/dev/** rw," sudo cat /etc/apparmor.d/usr.bin.nano abi , include /usr/bin/nano { include include include /etc/nanorc r, /etc/nsswitch.conf r, /etc/passwd r, /usr/bin/nano mr, owner /home/*/dev/ rw, owner /home/*/dev/** rw, } Here is an example of an AppArmor profile configuration that restricts the clang compiler's write permissions to to temporary directories with "include " as well as the "dev" directory that is in their home directory by specifically whitelisting the"home/*/dev/" directory and all of its sub directories for the file "owner" which in this case will be the user "josh".owner /home/*/dev/ rw," and " owner /home/*/dev/** rw," abi , include /usr/lib/llvm-18/bin/clang { include include include include include /etc/ld.so.cache r, /etc/locale.alias r, /etc/lsb-release r, /usr/bin/x86_64-linux-gnu-ld.bfd mrix, /usr/include/** r, /usr/lib/llvm-18/bin/clang mr, /usr/lib/llvm-18/bin/clang mrix, /usr/local/include/ r, owner /home/*/dev/ rw, owner /home/*/dev/** rw, } This is an example of an audit log output of when a user named "josh", who is in the "devs" group, tries to use a development tool, in this case, the nano text editor, outside of an authorized development directory. sudo cat /var/log/audit/audit.log type=SYSCALL msg=audit(1759800630.117:1734): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5fc9c5111130 a2=c1 a3=1b6 items=1 ppid=5018 pid=19069 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts3 ses=3 comm="nano" exe="/usr/bin/nano" subj=/usr/bin/nano key="access"ARCH=x86_64 SYSCALL=openat AUID="josh" UID="josh" GID="josh" EUID="josh" SUID="josh" FSUID="josh" EGID="josh" SGID="josh" FSGID="josh" type=CWD msg=audit(1759800630.117:1734): cwd="/home/josh" type=PATH msg=audit(1759800630.117:1734): item=0 name="./" inode=15073282 dev=08:02 mode=040750 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="josh" OGID="josh" type=PROCTITLE msg=audit(1759800630.117:1734): proctitle=6E616E6F00746573742E747874 I was unsuccessful in using SELinux on Fedora to achieve the same results as SELinux's label-based implementation, as it proved extremely difficult to enable many applications, in this case, development controls, to have shared access to a single specific directory. One limitation is the inability to limit the use of common interpreters, such as Python, which are used for system-related functions. Restricting Python is advised against, as it may cause dependent software to break. sudo aa-genprof /usr/bin/python3 /usr/bin/python3.12 is currently marked as a program that should not have its own profile. Usually, programs are marked this way if creating a profile for them is likely to break the rest of the system.If you know what you're doing and are certain you want to create a profile for this program, edit the corresponding entry in the [qualifiers] section in /etc/apparmor/logprof.conf. End User PC Side Control Implementation - Secondary "Developer" User Accounts With this control, users who are members of development groups are assigned secondary accounts from which they can access with ' runas' on Windows OSes or ' su' on Unix/Linux OSes. A login prompt to access the secondary profile should be required as an added security measure. These secondary accounts will have the necessary permissions to read from, write to, and execute from designated development directories. In my lab environment, I tested this on Fedora and Ubuntu. I was able to initially log in a user as a non-developer user outside of the "devs" group; however, I was unable to prevent users from logging directly into a developer who is a member of the "devs" group. Additionally, I was unable to adequately restrict the developer user to only writing to specific development directories using developer tools, as I was unable to granularly restrict write permissions for individual applications. Due to AppLocker's limitation, in which it is not able to restrict where a whitelisted application is able to write to, as it only allows or blocks applications from running and does not control the behavior of applications after they're launched, [7] I decided to no longer further pursue it as a viable candidate for evaluation. End User PC Side Control Implementation - Secondary "Developer" Machines With this control, users who are members of development groups are assigned secondary development machines instead of secondary accounts. These secondary machines can be physical or virtual. With virtual machines, this approach may also allow developers to have limited elevated permissions from within the VM, as the VM will enable more isolation and sandboxing. One major disadvantage is that this approach can be more expensive to implement and manage. Since I was unable to find a viable solution to restrict where development applications on Windows operating systems can write, this further supports the case for secondary Linux developer machines with AppArmor configured. This is especially the case when a primary Windows machine is required for non-development office work while the software being developed is intended to be run on a Linux or Unix server. Conclusion Shadow software development, a subset of shadow IT, can be mitigated through the implementation of adequate end-user controls on personal computers. These controls must ensure that only authorized users can access development tools and use them in a compliant and easy-to-audit manner. These control objectives can be achieved through proper network controls, as well as Mandatory Access Control (MAC), which utilizes centrally managed group permissions to restrict access to developer tools to members of a designated developer group. Additionally, AppArmor can be used to ensure that developer tools are only able to write to designated directories. These controls and their implementations encompass PO.5 - 'Implement and Maintain Secure Environments for Software Development of the SSDF. [ 6 ] Future Work Further evaluation on SELinux should be considered, as it has not been entirely ruled out as a viable candidate, even though its configuration would likely not be trivial to implement or even maintain for this use case. User experience testing should also be performed using a development environment with these controls implemented, ideally in an enterprise environment. Definitions [a] Mandatory Access Control - An access control policy that is uniformly enforced across all subjects and objects within a system. A subject that has been granted access to information is constrained from: passing the information to unauthorized subjects or objects; granting its privileges to other subjects; changing one or more security attributes on subjects, objects, the system, or system components; choosing the security attributes to be associated with newly created or modified objects; or changing the rules for governing access control. Organization-defined subjects may explicitly be granted organization-defined privileges (i.e., they are trusted subjects) such that they are not limited by some or all of the above constraints. Mandatory access control is considered a type of nondiscretionary access control. [ 4 ] and [ 5 ] Declarations Disclaimer The research, observations, and proposals presented in this paper are my own and do not represent any company or organization I have worked for or with. References Silic, Mario & Back, Andrea. (2014). Shadow IT – A view from behind the curtain. Computers & Security. 45. 10.1016/j.cose.2014.06.007. Pimentel, Brandon. “The Cost of Data Breaches.†Thomson Reuters Law Blog , 11 Dec. 2024, legal.thomsonreuters.com/blog/the-cost-of-data-breaches/. Zimmermann, S., Rentrop, C., Felden, C. Managing Shadow IT Instances - A Method to Control Autonomous IT Solutions in the Business Departments. Americas Conference of Information Systems, 2014, 1-12. NIST (2020). Security and Privacy Controls for Information Systems and Organizations . https://doi.org/10.6028/nist.sp.800-53r5 mandatory access control (MAC) - Glossary | CSRC https://csrc.nist.gov/glossary/term/mandatory_access_control Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1 : https://doi.org/10.6028/nist.sp.800-218 jsuther1974. (2024, January 10). Security considerations for AppLocker . Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/security-considerations-for-applocker Additional Declarations The authors declare no competing interests. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-7811422","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":526754102,"identity":"7bcdcd42-fc83-40bb-b81d-6136f6fd1167","order_by":0,"name":"Joshua Nathaniel Haupt","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAs0lEQVRIiWNgGAWjYBACxgYGNoaPDWB2AvFaGGeCtLARqwWklpkXooVIwNze/uyx7Q67xO3yDQ8YflRsI8JhPWfMjXPPJCfubGNIAHJuE6FlRg6bdG4bc+KGYwwJzIxtRGlJfyZt2VZPkpYEM2nGtsOkaOk5YybZ23bceGdbQsJBovxiCAwxiZ9t1bLbmc8kPvhRQYyWBijDgIEn4QBh9UAgD2MYMLATp2MUjIJRMApGHgAA4mE9TdJ0ISAAAAAASUVORK5CYII=","orcid":"","institution":"Independent","correspondingAuthor":true,"prefix":"","firstName":"Joshua","middleName":"Nathaniel","lastName":"Haupt","suffix":""}],"badges":[],"createdAt":"2025-10-09 00:32:49","currentVersionCode":1,"declarations":{"humanSubjects":false,"vertebrateSubjects":false,"conflictsOfInterestStatement":false,"humanSubjectEthicalGuidelines":false,"humanSubjectConsent":false,"humanSubjectClinicalTrial":false,"humanSubjectCaseReport":false,"vertebrateSubjectEthicalGuidelines":false},"doi":"10.21203/rs.3.rs-7811422/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-7811422/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":93199695,"identity":"c57bc3fd-2b8c-49c0-8904-6bc2b3f13cdc","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"docx","order_by":0,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":35530,"visible":true,"origin":"","legend":"","description":"","filename":"ShadowITSoftwareDevelopmentEndUserLinuxPCSideMitigationControlswithMandatoryAccessControlandLogging1.docx","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/3843b9720c6817c3a309e136.docx"},{"id":93199699,"identity":"eec8f8b4-c544-4149-9301-e4af13ce1269","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"json","order_by":1,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":342,"visible":true,"origin":"","legend":"","description":"","filename":"rs7811422.json","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/9dbf8fa420cc1c02d9ee02d4.json"},{"id":93199700,"identity":"1bc68e3d-1f32-4561-9bd5-76b68108cb72","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"xml","order_by":2,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":34343,"visible":true,"origin":"","legend":"","description":"","filename":"rs78114220enriched.xml","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/6d3d1592c97a9bde9448fb37.xml"},{"id":93199697,"identity":"586826b2-ab50-493d-b2d3-6cb0505580f7","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"png","order_by":3,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":17858,"visible":true,"origin":"","legend":"","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/389f1599ba234b2ffd2ba4dc.png"},{"id":93200054,"identity":"da76d4a8-76f6-40d9-a2c2-451b644b4594","added_by":"auto","created_at":"2025-10-10 06:49:15","extension":"png","order_by":4,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":5834,"visible":true,"origin":"","legend":"","description":"","filename":"Onlinefloatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/d9046bcd209f4a5516070c22.png"},{"id":93199701,"identity":"4aa719be-44fa-4e6b-bfc3-a423d2ca0314","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"xml","order_by":5,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":33712,"visible":true,"origin":"","legend":"","description":"","filename":"rs78114220structuring.xml","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/13258c42406d91d430547891.xml"},{"id":93199703,"identity":"0e23fcde-ce7f-4ffd-8457-148c019c1940","added_by":"auto","created_at":"2025-10-10 06:41:15","extension":"html","order_by":6,"title":"","display":"","copyAsset":false,"role":"acdc-reference","size":38475,"visible":true,"origin":"","legend":"","description":"","filename":"earlyproof.html","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/ce7d9f5203a4088e2e8d48a2.html"},{"id":93200053,"identity":"3a38a0f5-c073-48db-8b03-572f96c3c9f5","added_by":"auto","created_at":"2025-10-10 06:49:15","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":20244,"visible":true,"origin":"","legend":"\u003cp\u003eShadow IT Implementation - Quality vs Risk Analysis [3]\u003c/p\u003e","description":"","filename":"ScreenshotFrom20250913185124.png","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/b36f46e0d57cf095d3227514.png"},{"id":93201077,"identity":"956b241b-e12f-49f6-99b9-3b430323ca3a","added_by":"auto","created_at":"2025-10-10 06:57:15","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":430219,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7811422/v1/cc35369c-ac24-426a-af0f-6e3eaeb5ad78.pdf"}],"financialInterests":"The authors declare no competing interests.","formattedTitle":"\u003cp\u003e Shadow IT Software Development - End User Linux PC Side Mitigation Controls with Mandatory Access Control and Logging\u003c/p\u003e","fulltext":[{"header":"Risks","content":"\u003cp\u003eThe risks associated with shadow IT are quite costly, with the global average cost of a data breach in 2024 being $4.88 million. The costs include expensive compliance violations, as well as legal and reputational risks, especially if sensitive data is compromised. [2]\u003c/p\u003e\n\u003cp\u003eBoth data breaches and integrity failures typically stem from mishandling data at rest, in transit, or in use.\u003c/p\u003e\n\u003cp\u003eData breaches can result from improper data handling, such as using sensitive customer information in non-secure testing databases, utilizing unauthorized external databases, employing vulnerable third-party software libraries, and hardcoding sensitive credentials instead of properly vaulting them using a platform like Hashicorp Vault.\u003c/p\u003e\n\u003cp\u003eData integrity compromise is a significant risk associated with shadow IT, as such solutions often lack robust testing and safeguards, and are frequently of lower quality. For instance, in a distributed Robotics Process Automation (RPA) project, a shared Microsoft Access database held critical workflow data. An accidental mouse movement deleted essential rows, disrupting the entire process mid-execution.\u003c/p\u003e\n\u003cp\u003eInadequate controls against shadow software development can provide new threat vectors for ransomware and insider attacks, as unauthorized tools may be leveraged by malicious actors.\u003c/p\u003e\n\u003cp\u003eFrom this diagram, by Zimmermann [3], you can see that how a shadow IT implementation should be handled is based on the correlation between the quality of the implementation and the relevance and criticality of the implementation. If a shadow IT implementation is of low quality, but high relevance and criticality, mitigation efforts often require renovation, or fixing, and if necessary, rebuilding it. On the other hand, if the quality of a shadow IT implementation is very high, it may be safe enough to just register the implementation. Instances of shadow IT implementations that are in between require some coordination, as some renovation or fixes may still be necessary before they can be registered for proper utilization.\u003c/p\u003e\n\u003ch3\u003eMotives - IT Side\u003c/h3\u003e\n\u003cp\u003eOn the IT side, shadow software development often results from developer frustration with the available tools and resources within the enterprise. This can be due to a lack of adequate testing environments or development tools, such as Integrated Development Environments (IDEs) or debugging tools, that are available for use. The frustration with, or even lack of, internal developer platforms is another cause. Obviously, if no internal development platform exists, it can be a chaotic free-for-all. However, even if one does exist, it is often the case that developers may not understand how to properly utilize it, often due to inadequate training. Additionally, they may also be frustrated with a lack of support for using the platform.\u003c/p\u003e\n\u003ch3\u003eMotives - Business Side\u003c/h3\u003e\n\u003cp\u003eOn the business side, there may be a lack of support from IT or other development teams to implement necessary solutions for the business. As a result, business users may experiment with no-code / low-code platforms as well as Robotic Process Automation (RPA).\u003c/p\u003e\n\u003ch3\u003eControl Objectives\u003c/h3\u003e\n\u003cp\u003eThe proposed controls to be discussed for preventing shadow software development must satisfy the following conditions. 1.) They must ensure that only authorized users can access development tools. 2.) Both unauthorized and improper usage of development tools needs to be logged to enable upstream auditing. These controls can be implemented on end clients and on the network.\u003c/p\u003e\n\u003ch3\u003eControls - End User Personal Computers (PCs)\u003c/h3\u003e\n\u003col\u003e\n \u003cli\u003eRequire all network traffic to flow through the enterprise network to prevent the use of unapproved web and cloud services. If an end-user device is used remotely, all of its network traffic should be routed through an enterprise VPN. This control and its implementation are a prerequisite for\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eOnly allow approved software to be requested, downloaded, and installed from trusted internal repositories.\u003c/li\u003e\n \u003cli\u003eRestrict user access to development tools.\u003col style=\"list-style-type: lower-alpha;\"\u003e\n \u003cli\u003eRestrict the ability to request development tools to authorized users only.\u003c/li\u003e\n \u003cli\u003eRestrict the development tools users can request to only those that are necessary for their job function.\u003c/li\u003e\n \u003cli\u003eThrough Mandatory Access Control [a], restrict the ability to execute or run development tools based on the user\u0026apos;s group memberships. Unauthorized attempts to use development tools should be logged for upstream auditing. On Linux and other Unix-based systems, this can be implemented with proper permission configurations that are owned by the root user, allowing them to be centrally managed. These permissions need to restrict execution permissions to development tools to users of a specifically designated developers group. Further enforcement of proper usage of development tools and logging attempts at improper usage can be handled on Linux systems with centrally managed kernel security modules, such as AppArmor. Security-Enhanced Linux (SELinux) was evaluated in my experiments; however, during my lab experiments, I did not find it to be a practical tool for restricting the use of development tools on development systems used by individual users.\u003c/li\u003e\n \u003c/ol\u003e\n \u003c/li\u003e\n\u003c/ol\u003e"},{"header":"Lab Setup","content":"\u003cp\u003eFor the lab environment in which I tested my hypotheses, I used two separate laptops: one running Fedora 41 Workstation Edition and another running Ubuntu 24.04.3 LTS.\u003c/p\u003e\n\u003ch3\u003eEnd User PC Side Control Implementation - Use Mac to Restrict Access to Development Tools\u003c/h3\u003e\n\u003cp\u003eThe utilization of MAC to restrict development tools, such as IDEs, consoles, and text editors to write to and execute code in designated development directories is an additional control that should be implemented as it relates to PO.5 - \u0026apos;Implement and Maintain Secure Environments for Software Development of the SSDF. [6] This is more AppArmor, as both allow for fine-grained policies that can restrict who can access an application and where applications can write to. A drawback is having to maintain security policies for every development tool. Another drawback is that implementation can be challenging for specific groups that have access to it. However, this drawback can be mitigated by assigning developers a secondary account or secondary developer machines. Both of these controls not only relate to PO.5, but also enable streamlined auditability, as all activity involving these secondary accounts or machines can be logged and monitored as development activity.\u003c/p\u003e\n\u003cp\u003eIn my lab environment, on both the Fedora and Ubuntu machines, I was able to successfully restrict access to development tools, such as the nano, emacs, editors and the clang, gcc, and g++ compilers by setting the group ownership of binaries of the relevant binaries in /usr/bin/ to the \u0026quot;devs\u0026quot; group, and then removing the execute permissions for non owner or group members. I was also able to implement logging by configuring audit.d to monitor for failed execution, or \u0026quot;execve\u0026quot; system calls for non-system and non-root users.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eHere are the commands to restrict development application binaries to members of a specific group, in this case, the \u0026quot;devs\u0026quot; group.\u003c/p\u003e\n\u003cp\u003esudo groupadd devs\u003c/p\u003e\n\u003cp\u003esudo usermod -aG devs josh\u003c/p\u003e\n\u003cp\u003esudo chown root:devs /usr/bin/nano\u003c/p\u003e\n\u003cp\u003esudo chmod 710 /usr/bin/nano\u003c/p\u003e\n\u003cp\u003esudo chown root:devs /usr/bin/emacs\u003c/p\u003e\n\u003cp\u003esudo chmod 710 /usr/bin/emacs\u003c/p\u003e\n\u003cp\u003esudo chown root:devs /usr/bin/clang\u003c/p\u003e\n\u003cp\u003esudo chmod 710 /usr/bin/clang\u003c/p\u003e\n\u003cp\u003esudo chown root:devs /usr/bin/gcc\u003c/p\u003e\n\u003cp\u003esudo chmod 710 /usr/bin/gcc\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eHere are the required rules that need to be added as a rules file under /etc/audit/rules.d/.\u003c/p\u003e\n\u003cp\u003esudo cat /etc/audit/rules.d/denied.rules\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,execve -F\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eexit=-EACCES -F auid\u0026gt;=1000 -F auid!=-1 -F key=access\u003c/p\u003e\n\u003cp\u003e-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,execve -F\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eexit=-EPERM -F auid\u0026gt;=1000 -F auid!=-1 -F key=access\u003c/p\u003e\n\u003cp\u003e-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,execve -F\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eexit=-EPERM -F auid\u0026gt;=1000 -F auid!=-1 -F key=access\u003c/p\u003e\n\u003cp\u003e-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,execve -F\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eexit=-EACCES -F auid\u0026gt;=1000 -F auid!=-1 -F key=access\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThis is what a user outside of the \u0026quot;devs\u0026quot; group will see when they try to run a restricted development tool, which in this case is nano.\u003c/p\u003e\n\u003cp\u003enondev@josh-ubuntu-laptop:~$ nano\u003c/p\u003e\n\u003cp\u003ebash: /usr/bin/nano: Permission denied\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThis is an audit log that is generated when a user named \u0026quot;nondev\u0026quot; who is outside of the \u0026quot;devs\u0026quot; group tries to run a restricted development tool such as nano.\u003c/p\u003e\n\u003cp\u003esudo cat /var/log/audit/audit.log\u003c/p\u003e\n\u003cp\u003etype=SYSCALL msg=audit(1759799497.953:1669): arch=c000003e syscall=59 success=no exit=-13 a0=5a8a296a7c00 a1=5a8a296a7ba0 a2=5a8a2968d190 a3=5a8a296a7ba0 items=1 ppid=15098 pid=18160 auid=1000 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts4 ses=3 comm=\u0026quot;bash\u0026quot; exe=\u0026quot;/usr/bin/bash\u0026quot; subj=unconfined key=\u0026quot;access\u0026quot;ARCH=x86_64 SYSCALL=execve AUID=\u0026quot;josh\u0026quot; UID=\u0026quot;nondev\u0026quot; GID=\u0026quot;nondev\u0026quot; EUID=\u0026quot;nondev\u0026quot; SUID=\u0026quot;nondev\u0026quot; FSUID=\u0026quot;nondev\u0026quot; EGID=\u0026quot;nondev\u0026quot; SGID=\u0026quot;nondev\u0026quot; FSGID=\u0026quot;nondev\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=CWD msg=audit(1759799497.953:1669): cwd=\u0026quot;/home/nondev\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=PATH msg=audit(1759799497.953:1669): item=0 name=\u0026quot;/usr/bin/nano\u0026quot; inode=394303 dev=08:02 mode=0100710 ouid=0 ogid=1002 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID=\u0026quot;root\u0026quot; OGID=\u0026quot;devs\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=PROCTITLE msg=audit(1759799497.953:1669): proctitle=\u0026quot;bash\u0026quot;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eIn my lab environment, I successfully tested this using AppArmor on the Ubuntu machine. I configured two separate users, one outside of a devs group and another in the devs group. The user outside of the devs group was restricted from running most development tools, such as editors and compilers. While the user in the devs group was able to use such tools only while working inside the designated dev directory.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eHere is an example of an AppArmor profile configuration that restricts the nano text editor\u0026apos;s write permissions to a \u0026quot;dev\u0026quot; directory that is in their home directory by specifically whitelisting the\u0026quot;home/*/dev/\u0026quot; directory and all of its sub directories for the file \u0026quot;owner\u0026quot; which in this case will be the user \u0026quot;josh\u0026quot;.owner /home/*/dev/ rw,\u0026quot; and \u0026quot; owner /home/*/dev/** rw,\u0026quot;\u003c/p\u003e\n\u003cp\u003esudo cat /etc/apparmor.d/usr.bin.nano\u003c/p\u003e\n\u003cp\u003eabi \u0026lt;abi/3.0\u0026gt;,\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;tunables/global\u0026gt;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e/usr/bin/nano {\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/base\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/bash\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/evince\u0026gt;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e/etc/nanorc r,\u003c/p\u003e\n\u003cp\u003e/etc/nsswitch.conf r,\u003c/p\u003e\n\u003cp\u003e/etc/passwd r,\u003c/p\u003e\n\u003cp\u003e/usr/bin/nano mr,\u003c/p\u003e\n\u003cp\u003eowner /home/*/dev/ rw,\u003c/p\u003e\n\u003cp\u003eowner /home/*/dev/** rw,\u003c/p\u003e\n\u003cp\u003e}\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eHere is an example of an AppArmor profile configuration that restricts the clang compiler\u0026apos;s write permissions to to temporary directories with \u0026quot;include \u0026lt;abstractions/user-tmp\u0026gt;\u0026quot; as well as the \u0026quot;dev\u0026quot; directory that is in their home directory by specifically whitelisting the\u0026quot;home/*/dev/\u0026quot; directory and all of its sub directories for the file \u0026quot;owner\u0026quot; which in this case will be the user \u0026quot;josh\u0026quot;.owner /home/*/dev/ rw,\u0026quot; and \u0026quot; owner /home/*/dev/** rw,\u0026quot;\u003c/p\u003e\n\u003cp\u003eabi \u0026lt;abi/3.0\u0026gt;,\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;tunables/global\u0026gt;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e/usr/lib/llvm-18/bin/clang {\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/base\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/bash\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/consoles\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/opencl-pocl\u0026gt;\u003c/p\u003e\n\u003cp\u003einclude \u0026lt;abstractions/user-tmp\u0026gt;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e/etc/ld.so.cache r,\u003c/p\u003e\n\u003cp\u003e/etc/locale.alias r,\u003c/p\u003e\n\u003cp\u003e/etc/lsb-release r,\u003c/p\u003e\n\u003cp\u003e/usr/bin/x86_64-linux-gnu-ld.bfd mrix,\u003c/p\u003e\n\u003cp\u003e/usr/include/** r,\u003c/p\u003e\n\u003cp\u003e/usr/lib/llvm-18/bin/clang mr,\u003c/p\u003e\n\u003cp\u003e/usr/lib/llvm-18/bin/clang mrix,\u003c/p\u003e\n\u003cp\u003e/usr/local/include/ r,\u003c/p\u003e\n\u003cp\u003eowner /home/*/dev/ rw,\u003c/p\u003e\n\u003cp\u003eowner /home/*/dev/** rw,\u003c/p\u003e\n\u003cp\u003e}\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThis is an example of an audit log output of when a user named \u0026quot;josh\u0026quot;, who is in the \u0026quot;devs\u0026quot; group, tries to use a development tool, in this case, the nano text editor, outside of an authorized development directory.\u003c/p\u003e\n\u003cp\u003esudo cat /var/log/audit/audit.log\u003c/p\u003e\n\u003cp\u003etype=SYSCALL msg=audit(1759800630.117:1734): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5fc9c5111130 a2=c1 a3=1b6 items=1 ppid=5018 pid=19069 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts3 ses=3 comm=\u0026quot;nano\u0026quot; exe=\u0026quot;/usr/bin/nano\u0026quot; subj=/usr/bin/nano key=\u0026quot;access\u0026quot;ARCH=x86_64 SYSCALL=openat AUID=\u0026quot;josh\u0026quot; UID=\u0026quot;josh\u0026quot; GID=\u0026quot;josh\u0026quot; EUID=\u0026quot;josh\u0026quot; SUID=\u0026quot;josh\u0026quot; FSUID=\u0026quot;josh\u0026quot; EGID=\u0026quot;josh\u0026quot; SGID=\u0026quot;josh\u0026quot; FSGID=\u0026quot;josh\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=CWD msg=audit(1759800630.117:1734): cwd=\u0026quot;/home/josh\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=PATH msg=audit(1759800630.117:1734): item=0 name=\u0026quot;./\u0026quot; inode=15073282 dev=08:02 mode=040750 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID=\u0026quot;josh\u0026quot; OGID=\u0026quot;josh\u0026quot;\u003c/p\u003e\n\u003cp\u003etype=PROCTITLE msg=audit(1759800630.117:1734): proctitle=6E616E6F00746573742E747874\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eI was unsuccessful in using SELinux on Fedora to achieve the same results as SELinux\u0026apos;s label-based implementation, as it proved extremely difficult to enable many applications, in this case, development controls, to have shared access to a single specific directory.\u003c/p\u003e\n\u003cp\u003eOne limitation is the inability to limit the use of common interpreters, such as Python, which are used for system-related functions. Restricting Python is advised against, as it may cause dependent software to break.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003esudo aa-genprof /usr/bin/python3\u003c/p\u003e\n\u003cp\u003e/usr/bin/python3.12 is currently marked as a program that should not have its own\u003c/p\u003e\n\u003cp\u003eprofile. Usually, programs are marked this way if creating a profile for\u0026nbsp;\u003c/p\u003e\n\u003cp\u003ethem is likely to break the rest of the system.If you know what you\u0026apos;re\u003c/p\u003e\n\u003cp\u003edoing and are certain you want to create a profile for this program, edit\u003c/p\u003e\n\u003cp\u003ethe corresponding entry in the [qualifiers] section in /etc/apparmor/logprof.conf.\u003c/p\u003e\n\u003ch3\u003eEnd User PC Side Control Implementation - Secondary \u0026quot;Developer\u0026quot; User Accounts\u003c/h3\u003e\n\u003cp\u003eWith this control, users who are members of development groups are assigned secondary accounts from which they can access with \u0026apos;\u003cem\u003erunas\u0026apos;\u003c/em\u003e on Windows OSes or \u0026apos;\u003cem\u003esu\u0026apos;\u003c/em\u003e on Unix/Linux OSes. A login prompt to access the secondary profile should be required as an added security measure. These secondary accounts will have the necessary permissions to read from, write to, and execute from designated development directories.\u003c/p\u003e\n\u003cp\u003eIn my lab environment, I tested this on Fedora and Ubuntu. I was able to initially log in a user as a non-developer user outside of the \u0026quot;devs\u0026quot; group; however, I was unable to prevent users from logging directly into a developer who is a member of the \u0026quot;devs\u0026quot; group. Additionally, I was unable to adequately restrict the developer user to only writing to specific development directories using developer tools, as I was unable to granularly restrict write permissions for individual applications.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eDue to AppLocker\u0026apos;s limitation, in which it is not able to restrict where a whitelisted application is able to write to, as it only allows or blocks applications from running and does not control the behavior of applications after they\u0026apos;re launched, [7] I decided to no longer further pursue it as a viable candidate for evaluation.\u003c/p\u003e\n\u003ch3\u003eEnd User PC Side Control Implementation - Secondary \u0026quot;Developer\u0026quot; Machines\u003c/h3\u003e\n\u003cp\u003eWith this control, users who are members of development groups are assigned secondary development machines instead of secondary accounts. These secondary machines can be physical or virtual. With virtual machines, this approach may also allow developers to have limited elevated permissions from within the VM, as the VM will enable more isolation and sandboxing. One major disadvantage is that this approach can be more expensive to implement and manage.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eSince I was unable to find a viable solution to restrict where development applications on Windows operating systems can write, this further supports the case for secondary Linux developer machines with AppArmor configured. This is especially the case when a primary Windows machine is required for non-development office work while the software being developed is intended to be run on a Linux or Unix server.\u003c/p\u003e"},{"header":"Conclusion","content":"\u003cp\u003eShadow software development, a subset of shadow IT, can be mitigated through the implementation of adequate end-user controls on personal computers. These controls must ensure that only authorized users can access development tools and use them in a compliant and easy-to-audit manner. These control objectives can be achieved through proper network controls, as well as Mandatory Access Control (MAC), which utilizes centrally managed group permissions to restrict access to developer tools to members of a designated developer group. Additionally, AppArmor can be used to ensure that developer tools are only able to write to designated directories. These controls and their implementations encompass PO.5 - 'Implement and Maintain Secure Environments for Software Development of the SSDF. [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e]\u003c/p\u003e\u003cdiv id=\"Sec12\" class=\"Section2\"\u003e\u003ch2\u003eFuture Work\u003c/h2\u003e\u003cp\u003eFurther evaluation on SELinux should be considered, as it has not been entirely ruled out as a viable candidate, even though its configuration would likely not be trivial to implement or even maintain for this use case. User experience testing should also be performed using a development environment with these controls implemented, ideally in an enterprise environment.\u003c/p\u003e\u003c/div\u003e\u003cdiv id=\"Sec13\" class=\"Section2\"\u003e\u003ch2\u003eDefinitions\u003c/h2\u003e\u003cp\u003e[a] Mandatory Access Control - An access control policy that is uniformly enforced across all subjects and objects within a system. A subject that has been granted access to information is constrained from: passing the information to unauthorized subjects or objects; granting its privileges to other subjects; changing one or more security attributes on subjects, objects, the system, or system components; choosing the security attributes to be associated with newly created or modified objects; or changing the rules for governing access control. Organization-defined subjects may explicitly be granted organization-defined privileges (i.e., they are trusted subjects) such that they are not limited by some or all of the above constraints. Mandatory access control is considered a type of nondiscretionary access control. [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e] and [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e]\u003c/p\u003e\u003c/div\u003e"},{"header":"Declarations","content":"\u003ch3\u003eDisclaimer\u003c/h3\u003e\n\u003cp\u003eThe research, observations, and proposals presented in this paper are my own and do not represent any company or organization I have worked for or with.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n\u003cli\u003eSilic, Mario \u0026amp; Back, Andrea. (2014). Shadow IT \u0026acirc;\u0026euro;\u0026ldquo; A view from behind the curtain. Computers \u0026amp; Security. 45. 10.1016/j.cose.2014.06.007.\u003c/li\u003e\n\u003cli\u003ePimentel, Brandon. \u0026acirc;\u0026euro;\u0026oelig;The Cost of Data Breaches.\u0026acirc;\u0026euro; \u003cem\u003eThomson Reuters Law Blog\u003c/em\u003e, 11 Dec. 2024, legal.thomsonreuters.com/blog/the-cost-of-data-breaches/.\u003c/li\u003e\n\u003cli\u003eZimmermann, S., Rentrop, C., Felden, C. Managing Shadow IT Instances - A Method to Control Autonomous IT Solutions in the Business Departments. Americas Conference of Information Systems, 2014, 1-12.\u003c/li\u003e\n\u003cli\u003eNIST (2020). \u003cem\u003eSecurity and Privacy Controls for Information Systems and Organizations\u003c/em\u003e. https://doi.org/10.6028/nist.sp.800-53r5\u003c/li\u003e\n\u003cli\u003emandatory access control (MAC) - Glossary | CSRC https://csrc.nist.gov/glossary/term/mandatory_access_control\u003c/li\u003e\n\u003cli\u003eSouppaya, M., Scarfone, K., \u0026amp; Dodson, D. (2022). \u003cem\u003eSecure Software Development Framework (SSDF) Version 1.1\u0026acirc;\u0026euro;\u0026macr;:\u003c/em\u003e https://doi.org/10.6028/nist.sp.800-218 \u003c/li\u003e\n\u003cli\u003ejsuther1974. (2024, January 10). \u003cem\u003eSecurity considerations for AppLocker\u003c/em\u003e. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/security-considerations-for-applocker\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":true,"hideJournal":true,"highlight":"","institution":"Independent","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"cyber security, information security, software development","lastPublishedDoi":"10.21203/rs.3.rs-7811422/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-7811422/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eShadow Information Technology (IT) encompasses all hardware, software, or other solutions used by employees within the organisational ecosystem that have not received formal approval from the IT department. Shadow IT is a problem in many large organizations that handle sensitive information and infrastructure. [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e] Shadow software development is a subset of shadow IT, where undocumented applications are developed and deployed within enterprise environments. This paper outlines the use of Mandatory Access Control and proper logging of attempted usage of development tools, such as controls that can be implemented on the end-user or client side, to mitigate the risk of shadow application development.\u003c/p\u003e","manuscriptTitle":"Shadow IT Software Development - End User Linux PC Side Mitigation Controls with Mandatory Access Control and Logging","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-10-10 06:41:10","doi":"10.21203/rs.3.rs-7811422/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"af762b8e-817d-42ce-ac8b-465f878dd806","owner":[],"postedDate":"October 10th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[{"id":55989662,"name":"Software Engineering"}],"tags":[],"updatedAt":"2025-10-10T06:41:10+00:00","versionOfRecord":[],"versionCreatedAt":"2025-10-10 06:41:10","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-7811422","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-7811422","identity":"rs-7811422","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}