DSP Operational Framework Digital Service Provider Webinar Presented

DSP Operational Framework Digital Service Provider Webinar Presented

DSP Operational Framework Digital Service Provider Webinar Presented by: Martin Mane Digital Partnership Office, ATO 28 February 2018 WHAT WE WILL COVER | DSP OPERATIONAL FRAMEWORK Overview of the DSP Operational Framework Creating a multi dimensional assessment process Categorising the risk of our APIs Consultations Requirements Transition and Timeframes Future of the DSP Operational Framework UNCLASSIFIED: Webinar DSP Operational Framework 2 OVERVIEW | DSP OPERATIONAL FRAMEWORK The Digital Service Provider (DSP) Operational Framework (the Framework) is part of the ATO response in recognising and responding to risks posed by application programming interface (API) based wholesale digital services. Through the implementation of ATO APIs and services, DSPs make a range of taxation and superannuation related services available to the community. The ATO is at the forefront of API exposure and is significantly more advanced than other revenue agencies. Due to the sensitive nature of information consumed, there is a significant level of risk in releasing these services without adequate security measures in place. Why are we doing this The software industry is growing, we are witnessing a diverse range of developers entering the market and seeking to consume ATO APIs. As such, the ATO recognises we are creating new opportunities, the Framework aims to strengthen the security of the digital taxation and superannuation ecosystem by establishing a level of confidence and certainty. The Framework will enable the ATO to continue to invest in and extend the services made available through our digital wholesale channels. Securing the ecosystem will also provide increased levels of confidence to tax professionals, businesses and individuals. Furthermore, the ATO will publish each DSPs high level conformance outcomes, enabling full transparency and increased levels of comfort for potential and existing users. Factors creating a COMPOUNDING EFFECT in API services Exponential increases in opportunities (GOOD & BAD) Increased community connectivity & demand for availability (more access anytime) Increased range in types of APIs available (including data IN & data OUT) Significant increase in opportunities for enhanced client experience Exponential increases in volumes & payloads of API transactions Significant growth in the range, number & complexity of digital service providers Increased digital enrolments & consumption (e.g. by businesses, agents, others) Increased throughput velocity in ATO (i.e. more transactions are processing in real time) Increased automation in community & by service providers (enables mass volumes) UNCLASSIFIED: Webinar DSP Operational Framework The compounding

factors of API growth creates positive & negative opportunities. Significant increase in opportunities for cyber crime 3 CREATING A MULTI DIMENSIONAL ASSESSMENT PROCESS | DSP OPERATIONAL FRAMEWORK The DSP Operational Framework considers assessment in three dimensions. These are detailed below. API Risk Category High Risk 4 3 Access granted Potential access with additional conditions 2 Access denied or revoked Low Risk Se ity cur M ori onit ng Insufficientl y mature 1 Minimal R is k Low Medium R isk R isk D SP Risk R ating Hig h R isk

Sufficientl y mature API Risk Category DSP Risk Rating Security Monitoring Maturity The API Risk Category assigned to an API is The DSP Risk Rating is initially determined by The Security Monitoring Maturity rating shows critical to the 3D assessment model. It the registration and certification processes. It how a sufficiently mature capability would determines the minimum conditions required is based on the characteristics of the product adequately detect and defend ATO systems from to consume the API. or service offered to clients (e.g. cloud vs the compounding effects of API growth. desktop, tax professional vs business, client The API is risk categorised with the business base etc). area that requested the service/API. UNCLASSIFIED: Webinar DSP Operational Framework We are currently investing in additional toolsets and resourcing to enable more APIs to be It is reviewed on an as needs basis (e.g. exposed and managed for the growing range of changing DSP circumstances, breach events). DSPs. 4 CATEGORISING THE RISK OF OUR APIs | DSP OPERATIONAL FRAMEWORK As part of the Operational Framework, the ATO has categorised its APIs. Categorisation is based on the characteristics and potential fraud that could

occur through consumption of the API, such as the sensitivity and type of content. There may be more conditions placed on DSPs accessing high risk services than those accessing no risk services. The chart below highlights the characteristics of API risk ratings and provides examples of APIs that fit that category. 4. High risk API Request results/could result in updating personal or sensitive client data. Response contains/could contain personal or sensitive client data, not provided as part of the users request. 3. Medium risk API Request results/could result in viewing or updating of a clients tax or super account data. Response contains/could contain personal or sensitive client data, provided as part Examples View, update address, contacts, bank accounts. Fund validation service get Make a payment plan (could update FIA) Lodge ITR, FBT (could update FIA and name) SuperTICK and EmployerTICK Examples Account, transaction, lodgement list Outcome of assessment data Lodge an Activity Statement or excise return Add client/agent relationship Submit deferral request of the users request . Response validates personal, sensitive or private client data by way of interaction with the client register or ATO systems. 2. Low risk API Initial registration where the request or submission results in creating registration data in the client register or ATO systems. Request results/could result in viewing or updating tax or super registration data. Request results in providing account data attached/captured in ATO systems. Examples Add a tax role View AS role Apply for ABN or AUSkey Check ABN registration progress 3rd party transfer of data to ATO TFN decs, TPAR, Payment Summary Response contains no personal or sensitive client data and does not confirm by validation. 1. No risk API Access to data that is generic/intended to be publicly available. UNCLASSIFIED: Webinar DSP Operational Framework Examples Fund validations service list ABR Entitlement Questionnaire 5 CATEGORISING ATO APIs|DSP OPERATIONAL FRAMEWORK In consultation with key stakeholders from business, ATO APIs have been classified based on the characteristics of each service. The following is a sample of services: Service Name

Service Description This service allows a registered agent to request and retrieve a Client Communication List historical record of client communications for a single client, multiple clients or all clients. Client Update Financial Institution Details This service allows a reporting party or an intermediary to update a client's financial institution details. Individual Income Tax Return This service allows for the lodgment of an Individual Income Tax Return, along with any relevant associated schedules. Account List Client Update Relationships Add Payroll Event 2016 ABN Registration Application This interaction allows an initiating party to request a list of ATO account information for a particular client, which can be forecasted to a future date for penalties and interest. Accounts can also be requested by account identifier, account type or account category. This service will allow client to agent relationship/s to be added at the client level and/or account level. This services allows a business or their registered agent to notify the ATO of the payments made to the business' employees and the related Tax and Super obligations This service allows an application to be submitted with the ABR for an ABN/ TFN (TFN only for non-individuals). Bundled registration also support the inclusion of optional registration for tax roles. API Risk Rating Justification This service allows Agents to return a list of correspondence for all clients in the practice. Service will return TFNs for individual clients in the list, not provided as part of the original request. This service has the potential to update personal or sensitive information (FIA details) 4 4 4 3 3 2

2 TFN Declaration This service allows for the lodgment of a tax file number declaration/s by an Employer or their intermediary. 2 ABN Entitlement Questionnaire This interaction allows a party to request questions to be answered in order to apply for an ABN. 1 ABN Get Help Context The ABN Registration Help Service is a service that can be used to retrieve help details on completing the ABN Registration Service. 1 UNCLASSIFIED: DSP Operational Framework This service has the potential to update personal or sensitive information such as FIA or address details. This service will provide the ability to view account information. The identifier used as part of the request will also be returned i.e. the TFN entered will be returned with the response. This service updates non financial account information. It will also validate personal or sensitive information included in the users request. This service allows an employer to send a form to the ATO. This form attaches to the client record and no response is provided to the client beyond acknowledgement of successful transmission. This service returns a message providing a reference number and other optional items, such as the ABN in the case of a successful ABN application. This service allows an employer to send a form to the ATO. This form attaches to the client record and no response is provided to the client beyond acknowledgement of successful transmission. This service returns publicly available information which can be accessed through the ABR This service returns publicly available information which can be accessed through the 6 ABR CONSULTATIONS| DSP OPERATIONAL FRAMEWORK

The ATO identified 5 key areas which required a position in order to close known gaps in the security of our environment. These areas are: certification and assessment multi-factor authentication onshore-offshore data hosting supply chain and encryption. Focus groups including DSP and industry representatives were established to formulate these positions including how to transition existing DSPs. The solutions needed to strike the right balance between what is viable for DSPs to implement and maintain while still satisfying the risk appetite of the ATO. From these consultations the requirements were determined and agreed to. 51 Business and Industry representatives in total attended across 8 Industry Consultations We have and 4 micro focus consulted with groups a wide range of stakeholders 17 ATO Senior Executives from 11 branches 16 other Government Agencies May 2017 December 2017 UNCLASSIFIED: Webinar DSP Operational Framework 7 REQUIREMENTS|DSP OPERATIONAL FRAMEWORK This is a tiered model that considers: who hosts the software (client or DSP), how the software connects to the ATO, the risk profile of the API being consumed and the volume of taxpayer or superannuation records. Different requirements apply based on these characteristics. The registration process and security questionnaire will guide DSPs as to what requirements they need to meet and what evidence they need to provide. Hosted by the Client Characteristics Certification Direct connection to the ATO Connects to ATO via a DSP (eg Gateway) Hosted by the DSP Holds or transacts low volumes of taxpayer or superannuation

records Multi-factor Authentication Self-assessment Optional against: iRAP, ISO 27001, OWASP ASVS3.0 or SOC2 Consumes low risk APIs Consumes Self-assessment medium to against: high risk APIs iRAP or ISO 27001 Multi-factor Credential Required Onshore/ Offshore Data Hosting Supply Chain Visibility N/A N/A Solution to be developed Onshore by default with exceptions Encryption Encryption in transit Encryption at rest Payload Encryption Encryption in transit

required Optional N/A Solution to be developed Encryption at rest required Security Monitoring Required if DSP is using web services (hybrid desktop) N/A Security Monitoring is required. Holds or transacts significant volumes of taxpayer or superannuation records Controls applicable to all DSPs Independent assessment against: iRAP or ISO 27001 Registration process /questionnaire Software identifier in message Audit Logging minimum standard Personnel Security 8 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Certification and assessment To provide the ATO with a level of assurance that DSPs have robust security practices in place, the ATO has drawn on government and industry best practice to determine DSP certification requirements. The requirements for certification and assessment will vary and are dependent on the: type of service / software a DSP provides (desktop or cloud) API risk rating of the digital service a DSP is seeking to consume (minimal, low, medium or high risk) volume of accessible individual taxpayer or superannuation related records. Based on the combination of the above dependants, one of the following three actions will be required: self-assessment performed by a relevant internal representative in line with ISO / IEC 27001, ASVS3.0 or SOC2 self-assessment performed by a relevant internal representative in line with ISO / IEC 27001 independent assessment performed by a qualified, registered assessor in line with iRAP or ISO / IEC 27001. DSPs are able to request to use an alternative security standard if they feel it would be more suitable for their circumstances. These requests will be

assessed on a case-by-case basis. Evidence: Certification iRAP letter of compliance or iRAP assessor engagement details, ISO27001 documentation and Certificate of Compliance / Registration or Statement of Applicability with Certificate of Compliance, or Evidence of OWASP ASVS3.0 or SOC2 assessment UNCLASSIFIED: Webinar DSP Operational Framework 9 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Multi factor authentication Access to systems and the information they process, store or communicate need to be controlled through strong user identification and authentication practices. Multi-factor authentication uses independent means of evidence to assure a users identity. The three authentication factors are: Something one knows, such as a passphrase or a response to a security question, Something one has, such as a passport, physical token or an identity card, Something one is, such as biometric data, like a fingerprint, voiceprint or face geometry. Any two of these authentication factors must be used to achieve multi-factor authentication. If something one knows, such as the passphrase, is written down or typed into a file and stored in plain text, this evidence becomes something that one has and can defeat the purpose of multi-factor authentication. Authentication requirements will align to the Digital Transformation Agency's (DTA) Trusted Digital Identity Framework (TDIF) which is currently being developed. After the TDIF is established, DSPs will be required to either: use the current Cloud Authentication and Authorisation (CAA) solution with the addition of a multi-factor credential consume the government provided TDIF credential become a TDIF credential provider in their own right and consume their own credential. While the TDIF standards and solutions are being developed for use in software products the following requirements will be introduced: DSPs will need to review their security credential risks and develop a plan to manage the risks identified DSPs providing cloud services will implement a multi-factor credential solution or provide assurance of sufficient controls (to be considered on a case by case basis). An example of sufficient controls may be the use of real time authentication heuristics that inform how transactions are managed. TDIF credentials will provide multifactor authentication. Many DSP products and or services perform tasks outside of the tax and superannuation space. Multi-factor authentication will not be mandatory for users who will never be exposed to tax and superannuation records. Desktop or on premise software should have a user account with some form of authentication. Solutions that are targeted at clients with a higher volume of records should have more robust authentication solutions and controls (e.g. brute force prevention, account timeout and lock-out). Evidence Published product description User manual, user description, user instructions paired with screen shots of the user interface UNCLASSIFIED: Webinar DSP Operational Framework 10 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Onshore/Offshore data hosting Storing data in a foreign jurisdiction presents additional risks that must be considered. By default, the ATO expects DSPs to store data onshore. Consistent with guidelines for Australian, Prudential Regulation Authority (APRA) - regulated entities, the ATO expects DSPs to apply a cautious and measured approach when considering retaining data outside the jurisdiction it pertains to. APRAs Cross Industry Prudential Practice Guide CPG 235-Managing Data Risk, the ATO expect the following would normally be applied to the assessment and ongoing management of offshore data hosting: Enterprise frameworks such as security, project management, system development, outsourcing/offshoring management and risk management,

A detailed risk assessment, A detailed understanding of the extent and nature of the business processes and the sensitivity/criticality of the data impacted by the arrangement, A business case justifying the additional risk exposures. Consistent with APRAs Prudential Standard Guide SPG 231-Outsourcing, the ATO expects that DSPs would address the following specific risks and any other identified risks by: Country risk: the risk that overseas economic, political and or social events will have an impact upon the ability of an overseas service provider to continue to provide an outsourced service to the DSP, Compliance (legal) risk: the risk that offshoring arrangements will have an impact upon DSPs ability to comply with relevant Australian and foreign laws and regulations (including accounting practices), Contractual risk: the risk that a DSPs ability to enforce the offshoring agreement may be limited or completely negated, Access risk: the risk that the ability of a DSP to obtain information and to retain records is partly or completely hindered. This risk also refers to the potential difficulties or inability of the ATO to gain access to information using ATO information gathering powers, and Counterparty risk: the risk arising from the counterpartys failure to meet the terms of any agreement with the DSP or to otherwise perform as agreed. The ATO expects that an offshoring arrangement would typically include a provision around security and confidentiality of information. Additionally, where you are storing data outside of Australia you must: Make it clear to your customers that their data is being stored in a foreign jurisdiction, Apply the Australian Privacy Principles, Provide guidelines to your customers, where your customers use your services to collect and store data about other individuals (eg clients of tax practitioners, employees, etc.), on where and how their data is being managed Evidence Name of ASD certified data hosting provider, or data hosting providers details, including: provider name, provider location (onshore / offshore), redundancy location If data is stored offshore further evidence is required. See Additional conditions for offshore data hosting below for more information. UNCLASSIFIED: Webinar DSP Operational Framework 11 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Encryption The following encryption standards have been established: Encryption of data in transit Mandatory for all transmissions over public or shared network infrastructure to use ASD Approved Cryptographic Algorithms and Protocols. In majority of cases this will be TLS v1.2. Encryption of data at rest DSPs to use either full-disk, container, application or database Level encryption techniques, using ASD Approved Cryptographic Algorithms and Protocols. Payload-level encryption Encryption should be considered in conjunction with non-repudiation and integrity between the parties (via digital signatures). The encryption mechanism should be payload and messaging agnostic. Cryptographic Message Syntax (CMS) will form the basis of the solutions with a local customisation profile as required. Refer to page 242- 247 of the Australian Government Information Security Manual for the ASD Approved Cryptographic Algorithm standards. Payload Encryption Payload encryption can be used to provide end-to-end protection for sensitive or classified information. Payload encryption is the preferred solution for transporting sensitive or classified information through a supply chain. DSPs must, at a minimum, implement either payload encryption or supply chain visibility requirements when the solution is made available. Evidence Relevant combinations of: Screen shots (of the configuration page), Configuration files, Product data sheet/white papers (together with Product purchase/ownership documentation such as receipts, front page of a contract of product/support/service), Federal Information Processing Standard Validation documents (US government computer security standard, e.g. FIPS 140-2), Product Common Criteria Evaluation documents, or Product Evaluation Assurance Level (EAL) documents UNCLASSIFIED: Webinar DSP Operational Framework

12 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK Supply chain visibility A design principle of annotating the identity and functional role to the message is applicable to DSPs that read or modify sensitive data, where the payload is not encrypted end-to-end (e.g. payload-level encryption). The functional roles within a supply chain have been defined as: Data Collector Party responsible for the acquisition of data through user interface interaction or APIs Data Validator Party responsible for the verification of data types, structures, formats and or data values Data Transformer Party responsible for changing syntactic representation of data Data Analysis and Extraction Data Integrator Party responsible for combining data from multiple sources for use Data Provider Party responsible for the payload (which maybe encrypted) Party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data Data Transmitter Party responsible for the message with the payload. (e.g. ebMS3/AS4 transmission) Supply chain visibility will be part of a broader suite of controls, which includes audit logging, encryption, monitoring and certification of providers. When information is sent from one party to another (e.g. from a taxpayer to the ATO), the data can be sent through a number of different parties in a supply chain. Each party in the supply chain can perform one or more functional roles. The below design principles and functional roles will inform the development of a future technology solution to deliver supply chain visibility. Supply Chain Visibility involves annotating the identity and functional role to the message for every DSP that reads or modifies the data where the payload is not encrypted end-to-end (i.e. payload-level encryption). Where payload encryption has been implemented supply chain visibility will be optional. Design Principles 1. The technical solution will seek to balance the need for risk mitigation against need for operational effectiveness. 2. If a DSP reads or modifies any data, the message must be annotated with that DSPs identity and functional role(s) in the supply chain. 3. DSPs are not responsible for information after it has been securely delivered to an authenticated and authorised customer. 4. If a DSP routes a message, the message must be annotated with that DSPs Identity and functional role for operational support reasons. UNCLASSIFIED: Webinar DSP Operational Framework 13 REQUIREMENTS| DSP OPERATIONAL FRAMEWORK

Security monitoring practices Security monitoring should be implemented at different layers to detect anomalies and alert to indicators of fraud or misuse of a DSP product. It is expected that security monitoring will take place over three layers: Network/infrastructure layer Application layer Transaction (data) layer Software identifier in message The Product ID of the system that generates the original payload information (e.g. payroll or accounting system) for submission to the ATO rather than the intermediary (e.g. Sending Service Provider) that sends the ebms3 message to the ATO must be included in the message header. Exceptions apply in the SuperStream environment. Audit Logging minimum standard We appreciate each DSPs system is architected differently with limited universal design components. Standards for audit logging are therefore not in a prescriptive format but rather based on a number of key components. DSPs should consider their environment and what logging should be implemented and ensure that the logging records include relevant details. Personnel Security Personnel Security Procedures are required to be in place for all DSPs. It is expected that DSPs can evidence this by providing internal policy documents including descriptions of the process. Note: DSPs that are micro-businesses (one or two employees) may not require personnel security procedures unless contractors or non-employees have access to source code or tax or superannuation related information. Encryption key management plan An encryption key management plan is required to be in place, including public key infrastructure (PKI) keys in line with ASD/Industry guidelines. UNCLASSIFIED: Webinar DSP Operational Framework 14 TRANSITION AND TIMELINE | DSP OPERATIONAL FRAMEWORK The timeline below outlines key dates for existing DSPs to transition to the DSP Operational Framework including dates each requirement comes into effect. It is recognised the certification process can take time depending on the standard chosen and the maturity of the organisation. The ATO expects most DSPs will be able to complete the process in 3-6 months however longer timeframes will be required for some. The ATO will work with DSPs on an individual basis to determine an appropriate timeframe. Implemented 1 March All existing DSPs wishing to consume PLS services will be expected to commence the approval process Transition Timeframes to meeting the requirements March 2018 Existing DSPS need to commence the process of obtaining certification April 2018

May 2018 June 2018 July 2018 1 April All existing DSPs wishing to consume STP services will be expected to commence the approval process 1 May All existing DSPs wishing to consume taxation related services will be expected to commence by the approval process 1 June All existing DSPs wishing to consume superannuation related services will be expected to commence the approval process 1 July Any DSP that does not fall into prior categories will be expected to commence the approval process 31 March DSPs consuming tax practitioner products and services must implement MFA Encryption at rest/in transit Onshore/ Offshore data hosting Personnel security measures 30 June

DSPs consuming tax practitioner products and services must mandate the use of MFA 30 June Products and services where users have access to large volume of tax and superannuation records, DSP must implement MFA 1 July All products and services will be required to have audit logging capabilities Sept2018 30 September All other products and services hosted by the DSP, MFA must be implemented 30 September Products and services where users have access to large volume of tax and superannuation records, DSP must mandate the use of MFA Dec 2018 31 Dec All other products and services hosted by the DSP, the use of MFA must be mandated

Design for the supply chain visibility solution is expected to be completed by end of 2018 Design for the payload encryption solution is expected to be completed by end of 2018 Software identifier in message header UNCLASSIFIED: Webinar DSP Operational Framework 15 FUTURE | DSP OPERATIONAL FRAMEWORK The DSP Operational Framework is a maturity model and will continue to evolve to meet the needs of emerging technologies and changes in the DSP environment. Monitoring and information incidents Monitoring is considered a joint responsibility between the ATO and DSPs. The ATO conducts monitoring at the network, application and transaction layers. If anomalies or areas of concern are identified, we may re-assess your whitelisting suitability. This may include increasing the requirements that you need to meet or introducing additional requirements. The ATO will generally contact you or your representative unless exceptional circumstances apply. Where you identify a breach through your own monitoring controls you must notify the ATO immediately via your Account Manager to ensure appropriate action can be taken. Notifiable Data Breaches DSPs need to be aware of The Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act 1988 that establishes requirements for entities in responding to data breaches. Entities have data breach notification obligations when a data breach is likely to result in serious harm to any individuals whose personal information is involved in the breach. For further information on the Notifiable Data Breach scheme, please refer to https://www.oaic.gov.au/privacy-law/privacy-act/notifiable-data-breaches-scheme. Changing circumstances and annual re-assessment The ATO must be notified via your Account manager of any changes to your business or product environment, in relation to the information you supplied in your questionnaire response. Re-assessments will be conducted annually. In line with standard industry practice, certification (both independent and selfassessed) must be current. The ATO also reserves the right to undertake ad hoc reviews to ensure DSPs maintain alignment to the requirements of the framework. Expectations in meeting the requirements The ATO expects all DSPs will meet and maintain the relevant requirements of the DSP Operational Framework. The ATO will endeavour to work through nonconformance issues with DSPs, however failure to address these issues will result in restriction of access to services or de-whitelisting. The SBR Conditions of Use enables the ATO to lawfully suspend or terminate any software product, report or information from access to the SBR channel. The ATO is committed to the protection of tax and superannuation information and will treat issues of non-conformance seriously. UNCLASSIFIED: Webinar DSP Operational Framework 16

Recently Viewed Presentations

  • FIRST AID BASICS Everyone should know how to:

    FIRST AID BASICS Everyone should know how to:

    First Aid Treatment (Adult or child over 1 year old) Call 911 Identify yourself and ask them if you can help (get consent) Do not let a coughing person go away by themselves to the bathroom! When doing abdomina1 thrusts,...
  • Nutritional Management of Traumatic Brain Injury

    Nutritional Management of Traumatic Brain Injury

    Every 10 kcal/kg decrease within 5 to 7 days resulted 30-40% increased mortality risk HartlR, Gerber L, Ni Q, Ghajar J. Effect of Early Nutrition on Deaths Due to Severe Traumatic Brain Injury. Journal of Neurosurgery
  • 2/13/20 Powers and Roots Expressing powers of 10

    2/13/20 Powers and Roots Expressing powers of 10

    The expressions below are in ascending order. Find a possible value for x. Mr Draper and Mr Green share some money in the ratio 4:5. Mr Green gets £2 more than Mr Draper.
  • St. Michael's Powerpoint template

    St. Michael's Powerpoint template

    Meffe, Filomena Ministry of Health and Long Term Care $27,755 2019 - 2021 Title: "Resident perceptions of midwifery in obstetrical care: Just in time inter-professional education" Montalban, Xavier Biogen MA Inc. $180,000 2019 - 2027 Title: "A randomized, controlled, open-label,...
  • Logika Matematika

    Logika Matematika

    Kesimpulanadalahkonsepbaru yang diperolehdengancaramenurunkankonsep-konsepsebelumnya yang salingberhubungan. Pernyataanmajemukterdiridaripernyataansebelumkesimpulan ...
  • NCLEO DA CLULA http://slideplayer.com.br/slide/7600019/ NCLEO (nux: semente) Descoberto

    NCLEO DA CLULA http://slideplayer.com.br/slide/7600019/ NCLEO (nux: semente) Descoberto

    Title: Slide 1 Author: Thiago Last modified by: Juliana Created Date: 6/7/2011 10:41:42 PM Document presentation format: Apresentação na tela (4:3)
  • Nanoscale Lithography, Techniques and Technology

    Nanoscale Lithography, Techniques and Technology

    Nanoscale Lithography. Nanolithography is the branch of nanotechnology concerned with the study and application of fabricating nanometer-scale structures, meaning patterns with at least one lateral dimension between 1 and 100 nm.
  • Prezentace aplikace PowerPoint

    Prezentace aplikace PowerPoint

    Times New Roman Arial Calibri Comic Sans MS Wingdings Symbol Default Design Headache Headache Headache - classification Headache - classification Headache - classification Migraine Tension type headache Trigeminal autonomic cephalalgias (TACs) Other primary headaches Headache Headache Migraine Pathophysiology of migraine...